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ABSTRACT 


The  Army  and  Air  Force  have  interest  in  the  development  of  a  Joint  Precision 
Aerial  Delivery  System  (JPADS)  that  could  remotely  and  accurately  resupply  dispersed 
and  geographically  isolated  ground  forces.  The  Marine  Corps  has  requested  options  that 
offer  increased  accuracy,  lighter  payloads,  greater  stand-off  distances  and  reduced  cost. 
To  date,  most  research  has  resulted  in  a  series  of  large,  expensive  and  platform- specific 
solutions,  which  do  not  capitalize  on  the  enhanced  range  and  capability  afforded  by 
existing  and  commercially  available  unmanned  aerial  system  technology.  The  systems 
engineering  processes  contained  in  the  conceptual  and  preliminary  design  phases 
are  utilized  to  investigate  and  develop  a  potentially  low-cost  alternative  to  existing 
systems.  Using  an  Agile  methodology,  individual  components  are  designed  and 
incorporated  into  an  integrated  aerial  system  that  utilizes  an  autonomously  guided  and 
controlled  ram-air  parachute  delivered  from  an  unmanned  aerial  platform. 
Employment  of  the  low-cost  micro-light  weight  class  of  JPADS  has  the  potential 
to  provide  all  services  with  a  near-term  platform  to  remotely  deliver  diverse 
logistical  and  sensor  payloads  while  minimizing  risk  to  forces. 
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EXECUTIVE  SUMMARY 


Aerial  delivery  systems  (ADSs)  have  a  well-documented  history  of  affecting  the 
military  battlefield  at  both  the  strategic  and  operational  levels  for  the  better  part  of  the 
last  century,  and  recent  technological  advances  have  facilitated  an  extraordinary  increase 
in  the  precision  and  accuracy  of  these  systems.  The  range  of  payload  sizes  and  weights 
has  continued  to  expand,  as  have  demands  for  increased  accuracy  and  reliability 
associated  with  delivery.  Technological  advancements  in  ram-air  parachute  design, 
unmanned  aerial  vehicles  (UAVs)  and  inertial  navigation  systems  (INSs)  continue  to 
generate  expanded  interest  by  the  United  States  Marine  Corps  (USMC)  in  bringing 
smaller  payload  sizes,  and  their  associated  capabilities,  to  the  modem  tactical  battlefield. 
This  research  applies  a  systems  engineering  approach  to  design  a  prototype  micro-light 
weight  class  precision  aerial  delivery  system  (PADS)  to  determine  whether  low-cost, 
commercial-off-the-shelf  (COTS)  navigation  components  can  provide  sufficient  accuracy 
and  reliability  to  close  the  capability  gap  between  the  systems  currently  in  operation  and 
the  combat  operational  need  for  rapid-response,  tactical  logistical  resupply  in  austere  and 
dispersed  locations. 

In  order  to  address  the  primary  research  question,  a  brief  summary  on  the  history 
of  PADSs  and  descriptions  of  the  general  classes  are  included.  The  aerodynamic 
fundamentals  of  ram  air  parachutes  are  briefly  discussed,  and  an  introduction  to  the 
terminology  used  in  the  development  and  testing  of  PADSs  is  provided.  Previous  Naval 
Postgraduate  School  (NPS)  research  in  the  development  of  the  Blizzard  autonomous 
aerial  delivery  system  (AADS),  as  well  as  methods  for  updating  and  enhancing  PADS 
navigational  accuracy  are  presented.  The  standard  measures  of  performance  (MOPs)  and 
measures  of  effectiveness  (MOEs)  used  for  the  development  of  PADSs  are  described,  as 
well  as  the  application  of  the  Agile  methodology  in  systems  engineering.  Several 
potential  additional  PADS  mission  areas  also  are  summarized. 

The  application  of  traditional  and  Agile  system  engineering  methodologies  is 
explained,  including  the  various  technical  activities  associated  with  the  conceptual  and 
preliminary  design  phases.  The  core  problem  that  PADSs  are  designed  to  resolve  is 


identified,  and  subsequently,  the  basic  PADS  functions  are  listed  for  both  operational  and 
experimental  settings.  The  needs,  wants  and  concerns  of  several  stakeholders  are  detailed, 
as  well  as  the  design  criteria  that  influenced  conceptual  design.  Points  of  contrast 
between  operational  and  experimental  system  design  criteria  are  highlighted.  Several 
architecture  decisions  are  described  including  the  influence  of  shifting  design 
considerations  on  the  architectural  evolution.  The  operational  concept  for  employment  of 
PADSs  is  discussed  and  a  functional  analysis  is  specified. 

Subsequently,  the  conceptual  and  preliminary  design  of  a  Snowflake  ADS  and 
several  additional  components  of  the  Blizzard  AADS  are  described.  The  specifications 
for  the  two  types  of  UAVs  that  were  utilized  in  flight-testing  are  included.  Several 
iterations  and  a  final  prototype  design  are  summarized,  including  the  installation  and 
usage  of  two  types  of  commercial-off-the-shelf  (COTS)  available  autopilot  computers.  A 
description  of  the  final  design  for  a  power  distribution  sub-system  is  detailed,  as  early 
iterations  contributed  to  unexpected  failures  in  testing  and  experimentation.  A  description 
of  each  type  of  ram  air  parachute  is  included,  as  well  as  the  three  types  of 
UAV/Snowflake  separation  sequences.  A  comparison  between  the  flight  control 
dynamics  of  fixed-wing  platforms  and  a  ram  air  parachute  platform  is  incorporated,  as  it 
proved  to  be  a  significant  challenge  in  the  implementation  of  COTS  technology. 

A  comprehensive  summary  of  65  flight  tests  over  a  nearly  ten-month  period,  and 
several  simulations  conducted  in  the  Aerodynamic  Deceleration  Systems  Center  (ADSC) 
laboratory  at  NPS  are  included.  The  results  from  the  flight  tests  are  correlated  with 
sequential  improvements  in  the  parachute  deployment  methods  that  were  derived  from 
failure  mode  analysis.  Additionally,  the  ability  of  each  autopilot  to  capture  and  retain 
valid  experimental  data  is  described,  as  it  directly  influenced  the  author’s  conversion 
from  the  original  flight  computer  to  a  second  type.  Various  lab  simulations  and  the 
mathematics  used  to  convert  recorded  data  to  a  more  useful  coordinate  frame  using 
quaternions  are  detailed.  Subsequently,  a  representative  flight  profde  is  described  and 
illustrated  to  facilitate  follow-on  control  system  development. 


xx 


In  summary,  the  application  of  systems  engineering  methodology  to  influence 
conceptual  and  preliminary  design  is  described  in  detail  and  utilized  throughout  prototype 
design.  While  full  operational  capability  was  not  realized  during  the  course  of  this 
research,  several  conclusions  were  identified,  including  the  potential  for  follow-on 
improvements  in  design.  Low-cost,  COTS  navigation  components  are  likely  to  provide 
sufficient  accuracy  and  reliability  to  close  the  capability  gap  between  the  PADSs 
currently  in  operation  and  the  combat  operational  need  for  rapid-response,  tactical 
logistical  resupply  in  austere  and  dispersed  locations.  However,  continued  research  is 
warranted  to  determine  whether  performance  and  reliability  requirements  can  be 
delivered  in  a  low-cost  manner. 
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I. 


INTRODUCTION 


A.  BACKGROUND 

Aerial  delivery  systems  (ADSs)  have  a  well-documented  history  of  affecting  the 
military  battlefield  at  both  the  strategic  and  operational  levels  for  the  better  part  of  the 
last  century,  and  recent  technological  advances  have  facilitated  an  extraordinary  increase 
in  the  precision  and  accuracy  of  these  systems.  The  range  of  payload  sizes  and  weights 
has  continued  to  expand,  as  have  demands  for  increased  accuracy  and  reliability 
associated  with  delivery.  Early  precision  aerial  delivery  systems  (PADSs)  were  designed 
and  constructed  to  deliver  large  payloads  for  strategic  and  operational  logistical  resupply 
with  a  predetermined  accuracy  specification.  The  United  States  Marine  Corps  (USMC) 
has  stated  that  “expanded  use  of  unmanned  systems  for  resupply  of  forward-based  units 
is  not  only  viable,  it  is  a  critical  operational  requirement”  (United  States  Marine  Corps 
[USMC]  2013,  28).  Technological  advancements  in  ram-air  parachute  design,  unmanned 
aerial  vehicles  (UAV)  and  inertial  navigation  systems  (INSs)  continue  to  generate 
expanded  interest  by  the  USMC  in  bringing  smaller  payload  sizes,  and  their  associated 
capabilities,  to  the  modem  tactical  battlefield. 

In  response  to  a  current  warfighting  capability  gap  in  the  ability  to  provide  tactical 
logistical  support  while  minimizing  risk  to  forces,  the  Office  of  Naval  Research  (ONR)  has 
developed  the  Autonomous  Aerial  Cargo/Utility  System  (AACUS)  Innovative  Naval 
Prototype  (INP)  Concept  of  Operations  (CONOPS)  with  the  goal  of  providing  rapid-response 
payload  delivery  by  utilizing  advanced  autonomous  capabilities.  ONR  expected  that 
developed  systems  should  be  able  to  take  advantage  of  unmanned  vertical  takeoff  and 
landing  (VTOL)  capabilities  and  provide  reliable  delivery  of  medical  and  logistical  supplies 
to  geographically  dispersed  units  in  austere  locations  and  environments.  The  AACUS  INP 
CONOPS  also  includes  the  additional  complexity  of  landing  area  obstacle  detection  and 
avoidance,  and  autonomous  landing  at  unprepared  landing  sites  and  the  ability  for  terminal 
users  to  execute  supervisory  control  without  specialized  training  (Office  of  Naval  Research 
[ONR]  2012,  2). 
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Advances  in  PADSs  have  potentially  merged  with  the  capability  shortfalls 
highlighted  in  the  AACUS  INP  CONOPS  and  offer  a  potentially  simpler  and  less 
expensive  solution  than  some  of  the  technologies  and  solutions  envisioned  by  ONR. 
Focused  systems  engineering  research  is  warranted  in  the  design  and  applicability  of 
ultra-light  PADSs  as  a  potential  solution.  PADSs  have  the  potential  to  offer  fewer 
complications,  reduce  exposure  to  hostile  threat,  lower  cost,  and  increase  range  and 
endurance  capability.  The  capability  gap  summarized  by  ONR,  has  been  expressed  by 
numerous  Department  of  Defense  (DOD)  entities  and  can  potentially  be  closed  with  the 
use  of  PADSs  for  significantly  lower  costs  in  terms  of  both  financial  resources  and 
technical  complexity. 

B.  OBJECTIVES 

The  primary  objective  of  this  thesis  is  to  utilize  a  systems  engineering  approach  to 
design  a  prototype  micro-light  weight  class  PADS  and  to  answer  the  following  question: 

•  Can  low-cost,  commercial-off-the-shelf  (COTS)  navigation  components 
provide  sufficient  accuracy  and  reliability  to  close  the  capability  gap 
between  the  systems  currently  in  operation  and  the  combat  operational 
need  for  rapid-response,  tactical  logistical  resupply  in  austere  and 
dispersed  locations? 

Additionally,  secondary  research  questions  are 

•  What  are  the  operational  limitations  for  employing  a  micro-light  weight 
class  PADS? 

•  Can  various  systems  engineering  methodologies  be  applied  to  a  research 
area  to  provide  insight  and  improved  functionality  during  conceptual  and 
preliminary  design? 

•  What  are  the  key  differences  between  a  prototype  design  constructed  for 
operational  use  as  compared  to  a  design  constructed  to  support  scientific 
experimentation? 

•  Does  the  NPS  Systems  Engineering  curriculum  adequately  prepare  its 
students  to  work  within  a  multi-discipline  engineering  team  to  complete  a 
technical  thesis,  including  prototype  design,  construction  and  field 
experimentation? 
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C.  RESEARCH 

Preliminary  research  was  conducted  utilizing  open  source  government 
documentation,  discussions  with  unmanned  aerial  systems  (UAS)  and  PADS  subject 
matter  experts,  laboratory  experimentation  and  field  flight  experimentation  at  McMillan 
Airfield,  Camp  Roberts,  CA. 

The  following  computational  and  electronic  resources  were  utilized  during 
various  phases  of  this  research: 

•  APM  Planner  2.0:  Open  source  application  for  configuring,  testing  and 
calibrating  autonomous  vehicle  control  platforms.  Specifically,  APM 
Planner  2.0  was  used  with  the  Pixhawk  autopilot  in  early  research  and 
flight-testing. 

•  Rowley  CrossWorks  for  ARM  Version  3:  Comprehensive  C/C++ 
assembly  language  development  system  used  for  programming,  compiling 
and  debugging  an  X-Monkey  autopilot. 

•  MATLAB  2015B:  A  high-level  language  and  computational  software  tool 
used  extensively  for  data  analysis  of  flight  parameters  and  control  system 
design. 

D.  CURRENT  STATE 

The  Snowflake  ADS,  an  ongoing  research  project  at  the  Naval  Postgraduate 
School  (NPS),  started  in  2008  and  utilizes  a  series  of  commercially  available  sensors  that 
integrate  data  from  global  positioning  systems,  three  axis  accelerometers,  three  axis 
gyros,  a  magnetometer  and  a  barometric  altimeter.  The  previous  guidance  design  utilized 
a  series  of  highly  developed  and  specific  algorithms  that  facilitated  the  guidance  and 
control  of  a  two  skin  rectangular  parafoil.  Various  parafoils  could  be  attached  to  the 
Snowflake  system  to  facilitate  payloads  of  different  sizes.  Unfortunately,  a  good  portion 
of  the  resident  Snowflake  experts  had  departed  NPS,  and  a  significant  number  of  the 
components  required  for  ongoing  experimentation  were  no  longer  available. 

1.  Capabilities  Gap 

The  ONR  CONOPS  highlights  the  following  two  capability  shortfalls: 


3 


Executing  resupply  is  significantly  challenging  due  to  primarily  the  lack  of 
paved  roads  coupled  with  difficult,  mountainous  terrain  which  has 
diminished  the  effectiveness  of  traditional  means  of  overland  logistics 
movement  using  ground  transportation.  The  Joint  Force  needs  an  alternate 
means  to  provide  sustained,  time  sensitive,  logistics  support  over  widely 
dispersed  locations. 

Combat  in  urban  environments  has  shown  that  moving  a  casualty  can  be 
difficult  and  time  consuming.  Moving  an  individual  only  a  few  hundred 
yards  can  take  an  hour  or  more.  The  extended  lines  of  communication 
between  forces  and  their  forward  operating  bases  (FOBs)  (inclusive  of 
Medical  Evacuation  (MEDEVAC)  by  aircraft)  are  at  risk  of  enemy 
ambush  or  improvised  explosive  device  (IED)  attack  (ONR  2012,  3). 

The  USMC  also  has  requested  research  and  investment  in  the  usage  of  unmanned 
transportation  systems  and  robotic  systems  to  assist  with  resupply  to  the  engaged 
warfighter.  The  goal  is  tailored  delivery  while  minimizing  risk  to  human  life.  (USMC 
2013,  30)  In  general,  the  USMC  has  viewed  previously  developed  JPADSs  as  being  too 
large,  too  heavy,  too  expensive  and  not  responsive  enough  to  urgent  warfighter  needs. 

2.  Constraints 

The  principal  constraint  of  an  updated  Snowflake  ADS  is  that  it  must  be  designed 
to  close  the  current  capability  gap  (or  at  least  a  portion  of  it)  to  offer  increased  simplicity, 
reduced  exposure  to  hostile  threat  and/or  reduced  cost.  The  capability  gaps  described  do 
not  need  to  be  met  in  their  entirety.  As  such,  PADSs  that  can  close  one  of  the  capability 
gaps  with  significantly  enhanced  simplicity  should  not  be  excluded  from  consideration 
simply  because  it  does  not  perform  both.  The  ONR  CONOPS  indirectly  advocates  for  a 
solution  that  can  be  terminally  controlled  as  well  as  landed  and  re-launched  in  the  field. 
The  updated  Snowflake  ADS  must  be  able  to  accomplish  the  intended  delivery 
requirement,  and  if  it  can  sufficiently  deliver  payload  via  autonomous  parachute,  then  the 
complexity  of  landing  and  relaunching  can  be  avoided. 

E.  DESIRED  STATE 

The  desired  capability  resulting  from  this  research  is  a  systems  engineering 
approach  to  conceptual  and  initial  design  of  a  Snowflake  ADS  to  perform  small-scale 

logistical  resupply  in  a  more  efficient  manner  than  existing  systems  do.  The  research  is 
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designed  to  examine  the  capability  gaps  closely,  analyze  the  effective  stakeholder  needs 
and  design  a  potential  solution  to  achieve  the  objective  economically. 

F.  METHODOLOGY 

This  research  was  conducted  in  parallel  with  the  effort  of  Lieutenant  Commander 
Matthew  O’Brian,  from  the  Naval  Postgraduate  School  (NPS)  Undersea  Warfare 
Curriculum.  As  Lieutenant  Commander  O’ Brian  conducts  research  in  support  of  the 
Dynamic  Systems  and  Control  Track  in  the  Mechanical  Engineering  Department,  the 
author  intended  to  pair  with  O’Brian’s  research  effort  by  applying  a  systems  engineering 
methodology  to  maintain  a  direct  link  between  the  research  being  conducted  and 
resolution  of  a  stakeholder  need  or  requirement.  Utilizing  cross-domain  and  multi-field 
engineering  principles,  the  author  integrated  multiple  components  and  disciplines  ranging 
from  computer  programming,  electrical  engineering,  radio  frequency  communication, 
classic  control  and  aerodynamics.  The  author’s  intent  was  to  conceptually  and 
preliminarily  design  and  engineer  a  complete  logistical  delivery  system  which  could  be 
used  to  contribute  to  the  battlefield. 

To  assist  in  accomplishing  the  design  and  engineering,  the  author  used  a  hybrid 
systems  engineering  and  analysis  approach,  with  substantial  input  from  Blanchard  and 
Fabry cky,  as  well  as  an  Agile  systems  engineering  methodology  used  within  the  PADS 
industry  for  the  design  and  engineering  phases.  The  Blanchard  and  Fabrycky  methods 
were  used  to  correlate  effectively  the  stakeholder  needs  from  operational  users  and  to 
develop  an  updated  design  of  the  Snowflake  ADS  while  providing  traceability.  The 
author  also  used  elements  of  the  Agile  methodology  and  design  thinking  principles  to 
provide  targeted  iteration  within  the  conceptual  and  initial  design  phases. 

Though  the  parallel  effort  of  Lieutenant  Commander  O’ Brian  is  focused  on  the 
classical  and  modem  methods  of  control  associated  with  guidance  and  navigation  of  the 
Snowflake  ADS,  the  concepts  have  been  incorporated  from  conceptual  design.  The 
Snowflake  ADS  was  designed  to  capture  sufficient  data  and  serve  as  a  platform  for 
experimentation  to  support  the  development  of  the  various  plant  models  required  for 
effective  feedback  control. 
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G.  THESIS  ORGANIZATION 


To  address  the  objectives  and  research  questions  detailed  in  section  B,  this  thesis 
is  arranged  as  follows: 

•  Chapter  II  presents  a  summary  of  related  work.  It  includes  a  brief  history 
on  the  development,  classification  and  utility  of  Joint  Precision  Air  Drop 
Systems  (JPADSs),  the  fundamentals  of  a  ram-air  parachute,  the 
fundamentals  of  aerial  delivery  systems,  a  description  of  the  Blizzard 
autonomous  aerial  delivery  system  (AADS),  a  summary  of  two  techniques 
used  to  enhance  terminal  accuracy,  a  description  of  measures  of 
effectiveness  (MOEs)  and  measures  of  performance  (MOPs)  used  to 
assess  PADSs  and  an  overview  of  the  Agile  methodology  as  applied  to 
systems  engineering  a  PADS 

•  The  application  of  systems  engineering  methodology  is  covered  in 
Chapter  III.  It  includes  an  overview  of  conceptual  and  preliminary  design, 
the  problem  definition  and  needs  identification,  a  stakeholder  analysis, 
design  criteria  used,  the  operational  concept  for  PADSs  and  a  functional 
analysis 

•  Chapter  IV  details  the  design  of  the  Snowflake  system  components.  It 
includes  a  description  of  the  Arcturus  T-20  and  JUMP  20  UAVs,  overview 
of  the  Snowflake  ADS  including  the  design  of  the  autonomous  guidance 
unit  (AGU),  specifications  of  the  ram-air  parachutes  used,  summary  of  the 
various  parachute  deployment  sequences  and  a  description  of  the  flight 
control  dynamics  associated  with  ram  air  parachute  control 

•  Chapter  V  compiles  the  Snowflake  simulation  and  test  results.  It  includes 
an  analysis  of  the  failure  modes  encountered  during  flight 
experimentation,  methodology  used  for  conducting  coordinate 
transformation  and  analysis  of  representative  flight  test  results 

•  This  thesis  ends  with  Chapter  VI,  which  provides  a  conclusions  and  series 
of  recommendations.  It  includes  an  assessment  of  the  incorporation  of 
low-cost  technology  in  the  development  of  a  micro-light  weight  class 
PADS,  discussion  of  the  associated  operational  employment  limitations, 
description  of  the  utility  of  systems  engineering  methodologies  utilized  in 
conceptual  and  preliminary  design  as  well  as  several  technical 
recommendations  for  potential  improvements  to  the  Snowflake  ADS. 

In  summary,  PADSs  have  been  present  on  the  military  battlefield  for  an  extended 
period  and  have  been  asked  to  perform  traditional  logistical  supply  missions.  As  warfare 
has  evolved,  the  services  have  requested  PADSs  with  expanded  mission  capability 
through  increased  accuracy,  decreased  size,  longer  stand-off  ranges  and  reduced  cost. 
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This  chapter  articulates  the  primary  objective  of  this  thesis,  as  well  as  secondary  research 
questions  that  were  examined  in  the  course  of  research  and  experimentation. 
Additionally,  the  current  and  desired  end  state  of  the  research  is  addressed.  Finally,  this 
chapter  outlines  the  methodology  used  and  organization  of  the  thesis  to  assist  the  reader. 
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II.  RELATED  WORK 


A.  PREVIOUS  RESEARCH 

A  significant  amount  of  research  has  been  conducted  over  the  previous  50  years 
in  the  field  of  precision  aerial  delivery,  driven  largely  by  advances  in  controlled  gliding 
ram-air  parachutes  as  compared  to  the  uncontrolled  round  parachutes  that  preceded 
(Yakimenko  2015,1).  Driven  by  the  desire  to  deliver  logistics  remotely  with  increased 
accuracy,  dozens  of  PADSs  have  been  developed,  each  designed  to  deliver  a  diverse 
series  of  payload  sizes.  Additionally,  new  applications  have  continually  been  examined 
(Yakimenko  2015,  1).  The  following  summary  of  related  works  includes  the  history  and 
development  of  JPADSs,  a  basic  analysis  of  a  ram-air  parachute,  a  description  of  a 
previous  NPS  research  endeavor  to  field  an  AADS,  a  series  of  estimation  techniques  used 
to  refine  landing  accuracy,  a  proposed  set  of  MOEs  and  MOPs  used  to  evaluate  PADS 
effectiveness  and  a  description  of  a  systems  engineering  methodology  used  to  develop 
and  field  a  representative  PADS. 

B.  JPADS  PROGRAM 

The  Joint  Precision  Air  Drop  System  (JPADS)  was  a  United  States  (U.S.) 
Army/U.S.  Air  Force  program  jointly  developed  to  examine  potential  accuracy 
improvements.  The  goal  of  the  JPADS  program  was  to  develop  the  capability  to  deliver 
air  cargo  anywhere  in  the  world  within  24  hours.  The  U.S.  Air  Force  research  effort 
focused  on  the  development  of  a  mission  planning  system  that  could  aggregate  available 
wind  data  over  a  drop  zone  (DZ),  forecast  expected  wind  and  calculate  a  calculated  air 
release  point  (CARP).  This  release  point  should  minimize  the  landing  error  of  a 
conventional  unguided  aerial  delivery  system  (ADS)  (Yakimenko  2015,  10). 

In  conjunction  with  the  mission  planning  system,  the  U.S  Army  concurrently 
expended  research  effort  to  develop  a  series  of  AGUs  as  well  as  representative  systems  in 
the  classes  that  evolved  to  those  indicated  in  Table  1. 
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Table  1 .  JPADS  Categories.  Adapted  from  Defense  Industry  Daily  (20 1 6). 


JPADS  Weight  Class 

Weight  Range 

Micro-light  weight  (ML) 

-5-70  kg  (10-150  lb) 

Ultra-light  weight 

-100-300  kg  (250-700  lb) 

Extra-light  weight  (XL) 

-300  kg- 1.1  tons  (700-2,400  lb) 

Light  weight  (L) 

-2. 3-4. 5  tons  (5,000-10,000  lb) 

Medium  weight  (M) 

-4.5-19  tons  (10,000-42,000  lb) 

In  addition  to  simple  logistical  delivery,  the  technology  developed  though  the 
JPADS  program  has  proposed  applicability  that  extends  well  beyond  resupply.  In  his 
2015  summary  of  the  JPADS  program,  Yakimenko  proposes  the  following  additional 
military  and  security  applications: 

•  Provide  accurate  and  flexible  stealth  supply  to  special  forces  teams. 

•  Provide  navigational  guide  for  team  night  insertion. 

•  Support  pathfinder  operation. 

•  Deploy  acoustic  sensing  equipment  into  battlefield. 

•  Deploy  electronic  warfare  equipment. 

•  Deliver  leaflets  accurately. 

•  Deploy  nuclear,  biological  and  chemical  threat  sensors. 

•  Provide  “just  in  time”  supply  of  advancing  troops  (2015,  10-1) 

Additionally,  Yakimenko  also  proposes  that  PADS  capabilities  can  extend  well 
beyond  military  applications  to  provide: 

•  space  items  recovery  (as  a  final  stage  of  a  multistage  system) 

•  regular  supply  of  remote  locations 
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•  humanitarian  aid  and  disaster  relief  deployment  to  inaccessible  locations 
and  unprepared  DZs  including  potential  field  hospitals,  refugee  camps  and 
United  Nations  compounds 

•  all-weather  equipment  drop  for  search  and  rescue  operations 

•  equipment  supply  to  first  responders  in  disaster  areas 

•  equipment  delivery  into  rugged  mountain  areas 

•  sensing  equipment  and  video/radio  uplink  deployment 

•  medical  equipment  supply 

•  precision  delivery  of  buoys  and  lifeboats  at  sea  (2015,  1 1) 

C.  FUNDAMENTALS  OF  RAM-AIR  PARACHUTES 

In  2015,  Steven  Lingard  presented  an  updated  summary  on  the  fundamental 
design  of  a  ram-air  parachute.  Lingard  stated  (2015,  73 — 4)  that  the  ram-air  parachute,  or 
parafoil,  was  developed  in  the  early  1960s  with  the  effective  design  replicating  a  low- 
aspect  wing,  constructed  entirely  with  fabric  without  any  rigid  supporting  structure. 
Additionally,  Lingard  notes  that  flexibility  inherent  in  a  fabric  design  facilitated  packing 
and  airborne  deployment,  similar  to  previous  drag  parachute  designs,  though  the  airfoil 
characteristics  were  more  closely  related  to  wings  than  to  basic  drag  parachutes.  When 
viewed  from  above  or  below,  a  basic  parafoil  has  a  rectangular  shape,  but  the  cross 
section  is  a  series  of  individual  airfoils.  The  upper  surface  of  the  parafoil  is  joined  to  the 
bottom  surface  of  the  parafoil  by  a  series  of  flexible  fabric  ribs,  which  form  cells  as 
shown  in  Figure  1.  Lingard  added  that  the  leading  edge  of  the  wing  is  kept  open  to  allow 
air  to  enter  and  fill  the  parafoil,  yet  the  trailing  edge  is  sealed  to  retain  inflation.  There  is 
typically  a  series  of  apertures  cut  into  the  ribs  to  facilitate  the  flow  of  air  between  cells 
during  inflation  and  the  equalization  of  pressure  between  cells  once  the  parafoil  is 
inflated. 

Lingard  continues  (2015,  74)  that  to  preserve  the  basic  airfoil  shape  in  the  bottom 
surface,  there  is  a  series  of  suspension  lines  fastened  at  various  intervals  along  the  ribs 
between  cells.  A  rib  with  suspension  lines  becomes  a  loaded  rib,  and  a  non-loaded  rib  is 
one  without  suspension  lines.  Non-loaded  ribs  serve  to  separate  each  parafoil  cell  into 
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semi-cells  as  shown  in  Figure  1.  These  suspension  lines  are  typically  cascaded  into 
primary  suspension  lines  to  reduce  the  overall  drag  for  the  parafoil  system.  Stabilizer 
panels  can  be  added  to  the  edges  of  the  parafoil  to  assist  in  directional  stability  by 
channeling  the  flow  of  air  along  the  parafoil  rather  than  around  the  wingtip  which  creates 
a  more  unpredictable  vortex. 


Figure  1.  Basic  Ram- Air  Parachute.  Source:  Lingard  (2015). 


Unfortunately,  the  drag  associated  with  the  suspension  lines  becomes  a  significant 
factor  as  the  size  of  the  parafoil  is  increased.  As  a  result,  the  drag  of  the  parafoil  cannot  be 
considered  by  itself.  Instead,  a  systems  perspective  is  needed,  where  parafoil  drag  is  one 
contributor  to  the  overall  system,  which  also  includes  the  drag  of  the  suspension  lines.  In 
order  to  preserve  the  basic  flying  qualities  of  the  parafoil  and  to  reduce  the  length  of  the 
suspension  lines,  the  ram-air  wing  is  given  an  arc  anhedral,  which  is  also  referred  to  as  the 
crown  rigging  (2015,  84).  The  amount  of  anhedral  (a)  is  a  function  of  the  line  length  (R) 
and  the  span  of  the  parafoil  (b).  The  comparison  between  the  dihedral  angle  of  a 
conventional  wing  and  the  anhedral  angle  of  a  ram-air  wing  is  shown  in  Figure  2. 
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Figure  2.  Contrast  of  Conventional  Wing  Dihehdral  and  Ram-Air  Wing 

Anhedral.  Adapted  from  Lingard  (2015). 


Lingard  (2015,  92)  also  proposes  the  following  model  to  simplify  the  basic  forces 
acting  on  a  parafoil  system  in  flight.  The  free  body  diagram  shown  in  Figure  3 
graphically  describes  the  relationship  of  the  various  forces  acting  on  the  components  of 
the  parafoil  system.  In  this  diagram,  each  component  has  a  drag,  lift  and  weight  force, 
with  the  exception  of  the  suspension  line  weight,  which  is  considered  negligible.  The 
velocity  shown  (V)  represents  velocity  through  the  air  mass.  Obviously,  taking 
dynamically  changing  wind  velocity  into  account  creates  a  much  more  complex  series  of 
relationships.  The  glide  angle  (y)  is  the  angle  between  the  parafoil  velocity  vector  and  the 
horizontal  as  show  in  Figure  3. 
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Figure  3.  Ram- Air  Parachute  in  Steady  State  Gliding  Flight.  Adapted  from 

Lingard  (2015). 


To  maintain  effective  lateral  control  of  a  ram-air  parachute,  Lingard  (2015,  119) 
described  the  concept  of  trailing  edge  deflection  with  some  relative  approximations  for 
the  yawing  moment  that  could  be  generated  by  asymmetric  trailing  edge  deflection.  The 
yaw  rate,  in  radians  per  second,  can  be  determined  using  the  following  expression: 

V 

r  =  0.71-5. 

where  V  denotes  the  airspeed,  b  denotes  the  span  of  the  ram-air  parachute  and  Sa  denotes 
the  amount  of  asymmetric  trailing  edge  deflection  in  radians  per  second. 

D.  FUNDAMENTALS  OF  AERIAL  DELIVERY  SYSTEMS 

To  standardize  the  relationships  between  various  factors  considered  during  the 
execution  of  a  precision  aerial  delivery  (PAD)  mission,  Brown  and  Benney  (2005,  4) 
defined  the  following  terms,  each  of  which  is  illustrated  in  Figure  4: 

•  Impact  point  (IP):  designated  point  of  intended  landing 

•  Point  of  impact  (PI):  actual  point  of  landing 
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•  Air  release  point  (ARP):  point  of  release  of  the  airdrop  unit  from  the  drop 
aircraft 

•  Ballistic  trajectory:  trajectory  along  which  an  unguided,  drag-only  body 
would  fall  in  order  to  reach  the  IP 

•  Ballistic  ARP:  the  intersection  of  the  delivery  aircraft  flight  path  with  the 
ballistic  trajectory,  i.e.,  a  theoretically  perfect  release  point 

•  CARP:  Standard  airdrop  terminology  for  the  calculated  location  of  the 
ARP  based  on  estimated  winds 

•  Air  release  circle  (ARC):  a  circle  at  the  release  altitude,  centered  on  the 
Ballistic  ARP,  within  the  glide  performance  of  the  system  is  sufficient  to 
reach  the  IP. 


Figure  4.  Terms  Associated  with  Aerial  Delivery  Systems.  Source:  Brown 

and  Benney  (2005). 

The  location  of  the  CARP  becomes  significant  when  the  wind  estimation  contains 
error,  which  is  likely,  or  when  there  are  multiple  drops  intended  for  the  same  IPs.  To 
ensure  safe  separation  of  PADSs,  the  delivering  platform  will  incorporate  some  time 
between  successive  PADS  release,  which  will  correspond  to  a  positional  displacement 
requiring  compensation  during  the  PADS’s  flight  and  navigation  profile. 
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E.  BLIZZARD  A  ADS 

In  2008,  a  coordinated  effort  between  U.S.  Special  Operations  Command 
(SOCOM)  and  the  NPS  Aerodynamic  Deceleration  Systems  Center  (ADSC)  conducted 
research  to  design  a  system  for  ultra-light-weight  precision  aerial  delivery.  Researchers 
from  NPS  and  the  University  of  Alabama  presented  a  miniature  prototype,  termed  the 
Blizzard  AADS,  which  utilized  an  inertial  trajectory  and  an  estimate  of  surface  winds  to 
compute  a  final  standard-approach-pattem  and  landing  maneuver  into  the  wind.  Accuracy 
results  from  the  Blizzard  AADS  were  inside  of  10m  CEP  (Yakimenko  et  al.  2011,  1-2). 

The  Blizzard  AADS  consisted  of  a  four  major  components:  the  T-20  unmanned 
aerial  vehicle,  the  Snowflake  ADS,  a  ground  mission  command  and  control  center 
(MCCC),  and  an  optional  ground  target  weather  station.  The  MCCC  facilitated  the  entry 
of  target  coordinates;  the  weather  station  allowed  updated  target  area  winds  to  be  used  for 
landing  accuracy  improvements  and  the  T-20  delivered  the  payload  to  a  pre-determined 
launch  location.  The  Snowflake  ADS  was  a  small  4”x8”xl0”  payload  container 
consisting  of  avionics  and  control  actuators,  including  a  global  positioning  system  (GPS) 
receiver,  three-axis  accelerometers,  gyroscopes,  a  magnetometer  and  a  barometric 
altimeter  (Yakimenko  et  al.  2011,  2-4). 

The  Blizzard  AADS  proved  to  be  a  nearly  complete  fielded  system,  useful  for 
follow-on  research  and  concept  exploration.  The  research  proved  the  accuracy  of  the 
system  and  showed  that  enhancements  and  subsequent  examination  of  additional 
applications  were  possible. 

F.  POSE  ESTIMATION  AND  MONOCULAR  AUGMENTATION 

In  his  Ph.D.  dissertation,  Hewgley  (2014,  v)  provides  two  methods  to  aid  in 
enhancing  PADS  accuracy.  In  an  effort  to  better  estimate  the  winds  between  a  descending 
ADS  and  the  intended  point  of  landing  (POI),  Hewgley  assumes  a  logarithmic 
relationship  between  the  air  mass  height  and  the  horizontal  wind  velocity.  The  estimation 
technique  facilitates  a  better  estimation  of  the  PADS’s  computation  of  terminal  winds  and 
the  computation  of  a  landing  trajectory. 
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Utilizing  the  previously  described  Snowflake  ADS  as  an  experimentation 
platform,  Hewgley  developed  a  method  wherein  the  Snowflake  measured  real-time  wind 
speed  and  direction  aloft,  utilized  a  logarithmic  model  of  boundary  layer  winds  near  the 
surface  and  continually  computed  the  wind  direction  and  speed  that  it  would  fall  through 
during  the  remainder  of  the  descent.  This  method,  summarized  in  Figure  5,  was 
particularly  suited  for  shipboard  and  maritime  usage  in  which  the  course  and  speed  of  the 
ship  can  be  adjusted  to  produce  a  relatively  predictable  wind  (Hewgley  2014,  xxiii). 


Figure  5.  Logarithmic  Wing  Estimation  Used  for  Planning  Intended  Landing 

Point.  Adapted  from  Hewgley  (2014). 

Additionally,  to  assist  in  target  motion  estimation,  Hewgley  opted  to  utilize  a 
monocular  vision  camera.  The  monocular  system  was  selected  for  simplicity  and  a  cost 
reduction.  By  using  a  simple  geometric  projection,  a  homogeneous  coordinate 
transformation  and  a  subsequent  state-space  formulation,  the  Snowflake  ADS  utilized  its 
monocular  sensor  to  provide  navigation  adjustments  based  on  relative  motion  between 
the  sensor  and  the  target  (Hewgley  2014,  45).  Additionally,  Hewgley  provides  an 
unscented  Kalman  filter  (UKF)  algorithm  to  blend  the  target  in-target  and  out-of-target 
measurement  error  covariance  matrices  as  a  monocular  sensor  is  unlikely  to  retain  the 
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target  within  view  due  to  the  pendulum  oscillations  caused  by  the  descending  ram-air 
parachute  (Hewgley  2014,  90-91). 

G.  MEASURES  OF  PERFORMANCE  AND  EFFECTIVNESS 

Three  critical  operational  issues  (COIs)  were  created  to  guide  the  development  of 
JPADSs  in  the  mid-2000s,  which  were  subsequently  used  during  a  Joint  Military  Utility 
Assessment  (JMUA)  of  existing  technologies.  They  were 

•  COI  1.  Does  the  JPADS  system-of-systems  successfully  support  payload 
delivery  at  the  target  weights  and  standoff  distances  in  its  intended 
operational  environment? 

•  COI  2.  Does  the  JPADS  system-of-systems  provide  the  Joint  Task  Force 
(JTF)  Commander  with  an  enhanced  operational  capability? 

•  COI  3.  Is  the  JPADS  system-of-systems  suitable  for  employment  in  its 
intended  environments?  (Benney  et  al.  2005a,  1 1) 

1.  System  Reliability  and  Accuracy 

PADS  accuracy  was  described  in  detail  by  Brown  and  Benney  (2005,  3).  System 
reliability  was  defined  as  the  probability  of  a  PADS  successfully  reaching  a  location  near 
the  DZ  from  which  a  successful  guided  approach  and  landing  at  the  intended  IP  could  be 
achieved.  Terminal  accuracy  was  the  distance  from  IP  to  the  nearest  of  all  landing  points 
that  fall  within  a  specified  probability  level.  Overall  system  accuracy  was  defined  as  the 
distance  from  the  IP  to  the  nearest  of  all  landing  points  landing  within  a  specified 
probability  level.  These  relationships  are  summarized  in  Figure  6,  with  the  significant 
distinction  that  an  unreliable  system  is  still  characterized  as  a  valid,  though  inaccurate 
system. 
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Figure  6.  Relationship  Between  System  Accuracy,  Reliability  and  Terminal 
Accuracy.  Adapted  from  Brown  and  Benney  (2005). 


2.  Reliability:  Failure  Modes  and  Effects 

In  2015,  expanding  the  definitions  set  by  Brown  and  Benney,  Yakimenko 
characterized  five  potential  failure  modes  that  could  affect  the  reliability  of  the  PADS  as 
follows: 

•  air  carrier  missing  CARP  (which  is  especially  critical  for  unguided  ADSs 
or  PADSs  with  very  limited  control  authority) 

•  parachute  failure  to  open  (can  include  several  submodes  depending  on  the 
number  of  PADS  stages) 

•  parachute  or  control  line  damage 

•  failure  of  the  AGU  to  operate  properly 

•  excessive  actual  winds  aloft  (compared  to  predicted)  precluding  reaching 
the  DZ  even  if  everything  works  correctly  (2015,  14) 

H.  AGILE  METHODOLOGY 

In  addition  to  simply  developing  and  advancing  the  capabilities  of  PADSs, 
significant  advances  have  been  made  in  the  utilization  of  Agile  development 
methodologies  and  their  utility  in  executing  systems  engineering  through  the 
development  of  parachute  systems.  In  201 1,  Barber  et  al.  discussed  their  use  of  an  Agile 
methodology  as  an  alternative  to  the  conventional  Plan  Driven  Product  Development  Life 
cycles  (PD-PDLC),  or  “waterfall”  development  shown  in  Figure  7.  They  advocated  the 
three  essential  Agile  values  that  made  it  unique: 
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•  Requirements  are  too  important  to  be  left  to  the  beginning.  They  must 
evolve  with  user  interaction  and  interpretation  as  the  implications  come 
into  view. 

•  Planning  and  documenting  is  important,  but  following  the  plan 
documenting  details  is  not  as  important  as  satisfying  the  customer  with  a 
solution  that  works  correctly. 

•  The  systems  engineering  and  management  processes  emerge  to  fit  the 
circumstances  and  control  metrics  are  empirically  determined.  The 
methodology  does  not  specify  this  ahead  of  time.  (Barber  et  al.  201 1,  2) 


Figure  7.  PD-PLDC  “Waterfall”  Methodology.  Source:  Barber,  Montague 

and  Barello  (2011). 


Barber  et  al.  advocated  that  an  Agile  methodology  was  most  effective  when  the 
following  conditions  exist: 

•  Requirements  are  unstable  or  evolving. 

•  All  stakeholders  (customers,  managers,  developers,  testers)  are  in  a 
position  to  collaborate  as  requirements  evolve. 

•  Technical  innovation  is  essential  to  achieve  required  capability.  For  some 
programs,  innovation  is  not  just  “bonus”  from  clever  engineers,  but  an 
outright  necessity  for  the  success  of  the  effort.  (Barber  et  al.  201 1,  2) 

Usage  of  Agile  methodology,  shown  in  Figure  8,  has  proven  successful  in  the 
production  of  some  PADSs,  especially  when  the  level  of  engineering  effort  and 
complexity  require  it.  Barber  et  al.  stated  that  adjusting  requirements,  iterated  delivery 
and  face-to-face  interaction  was  a  superior  method  for  system  engineering,  and  the  idea  is 
sound.  The  Agile  methodology  can  be  applicable  to  projects  of  a  certain  size  and 
technical  complexity,  though  it  offers  no  increased  guarantee  of  delivering  a  product  on 
time  and  on  budget  when  compared  to  the  typical  DOD  Acquisition  Framework. 
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Lastly,  Barber  et  al.  discussed  the  architecture  decisions  made  through  the 
development  of  their  JPADS  design.  They  stated: 

Good  architecture  also  supports  cost-effective  development,  not  just  the 
resulting  design.  Top  level  architecture  decisions  evident  in  the  resulting 
JPADS  design  include: 


•  common  User  Interface  across  platforms  (LCD  Screen,  Mission  Planning, 
Rigging  etc.) 

•  common  Avionics  and  flight  software  across  all  platforms 

•  open  Source  Operating  System 

•  flight  software  extensible  to  new  canopy  designs  and  control  techniques 

•  suspended-type  AGU 

•  tool-less  connections  between  parachute  and  AGU 

•  easy  software  upgrade 

•  easy  access  to  flight  log  data 

•  common  canopy  structural  and  planform  features  to  maximize 
commonality  and  simplicity  of  packing  and  rigging  (Barber  et  al.  201 1,  9) 
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Figure  8.  Airborne  Systems  Agile  Methodology  for  U.S.  DOD  Programs. 

Source:  Barber,  Montague  and  Barello  (2011). 
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I.  SUMMARY 

This  chapter  summarized  some  of  the  recent  research  relevant  to  the  development 
of  PADSs,  including  weight  class  definitions  and  the  history  of  the  JPADS  program.  This 
chapter  also  described  the  potential  applicability  of  PADSs  beyond  logistical  resupply  to 
additional  mission  areas.  The  aerodynamic  fundamentals  of  ram  air  parachutes  were 
briefly  discussed,  as  well  as  an  introduction  to  the  terminology  used  in  the  development 
and  testing  of  PADSs.  Subsequently,  previous  NPS  research  in  the  development  of  the 
Blizzard  AADS,  as  well  as  methods  for  updating  and  enhancing  PADS  navigational 
accuracy  were  presented.  Standard  MOPs  and  MOEs  used  for  the  development  of  PADSs 
were  described,  as  well  as  a  summary  on  the  utility  of  Agile  methodology  in  systems 
engineering.  The  author’s  application  of  traditional  and  Agile  systems  engineering 
methodologies  to  design  a  low-cost  micro-light  weight  PADS  are  detailed  in  Chapter  III. 
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III.  SYSTEMS  ENGINEERING  METHODOLOGY 


A.  CONCEPTUAL  AND  PRELIMINARY  DESIGN  OVERVIEW 

Conceptual  and  preliminary  design  phases  of  a  systems  engineered  project  have 
several  activities  and  interactions  that  must  be  accomplished  to  ensure  the  design  is 
related  to  an  actual  stakeholder  need  responding  to  a  perceived  or  actual  problem. 
Blanchard  and  Fabrycky  highlight  several  of  these  steps  shown  in  Figure  9.  This  chapter 
will  focus  on  several  activities  within  these  phases  that  assisted  in  the  design  and 
development  of  several  prototype  micro-light  weight  class  PADSs,  as  well  as  some  of  the 
architecture  decisions  made  through  the  design  phase  of  an  update  to  the  NPS  Snowflake. 
While  preliminary  design  of  a  micro-light  weight  class  PADS  was  geared  toward 
operational  employment,  it  is  essential  to  note  that  the  author  did  need  to  make 
significant  deviations  from  an  operational  employment  scenario  to  support  adequate  field 
testing  and  experimentation.  In  a  sense,  the  author  became  the  primary  stakeholder  of  the 
preliminary  design,  as  it  was  designed  to  support  a  more  successive  development  that 
would  more  closely  match  an  operational  stakeholder  need. 
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Figure  9.  Technological  Activities  and  Interactions  within  the  Design 
Phases.  Adapted  from  Blanchard  and  Fabrycky  (201 1). 
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B.  PROBLEM  DEFINITION  AND  NEED  IDENTIFICATION 

Many  of  the  approaches  to  developing  and  constructing  PADSs  of  all  classes  are 
derived  from  the  three  core  COIs  identified  earlier.  Continued  exploration  and  research 
into  other  potential  mission  areas  for  micro-light  weight  class  PADSs  warrants  a 
revalidation  of  the  basic  problem  definition  and  identification  of  a  hypothetical 
stakeholder’s  needs.  The  core  problem  surrounding  any  type  of  precision  aerial  delivery 
is  that  there  is  a  person,  unit  or  organization  that  needs  (or  wants)  something  that  it  does 
not  have.  Aerial  delivery  is  more  suited  for  longer  ranges  between  the  current  location  of 
the  equipment  and  its  intended  location.  Additionally,  if  time  is  a  concern,  the  speed  of 
aerial  delivery  over  extended  ranges  is  preferred  over  alternative  means. 

From  a  military  perspective,  the  presence  of  hostile  or  adverse  factors  impeding 
delivery  is  a  concern  and  can  make  aerial  delivery  a  preferred  option.  In  consideration  of 
the  hostile  factors,  the  effective  need  is  for  delivery  with  a  minimum  of  risk  to  the 
delivery  method  as  well  as  to  the  intended  recipient.  For  example,  if  preparation  of  a 
helicopter-landing  zone  presented  an  increased  risk  to  isolated  military  forces,  then  the 
forces  may  well  consider  whether  the  logistical  supply  was  necessary.  The  cost 
associated  with  larger  classes  of  PADSs  have  been  accompanied  by  the  effective 
requirement  that  the  unit  being  supplied  collect  and  return  the  PADS  for  subsequent 
reuse. 

In  addition  to  the  operational  utility  of  employed  PADSs,  the  micro-light  weight 
class  design  engineered  for  this  thesis  also  presented  a  secondary  set  of  needs.  It  needed 
to  preserve  and  retain  experimental  data,  to  survive  repeated  flight  experiments,  to  be 
compatible  with  available  launch  platforms  and  parafoils,  and  finally,  to  support  the 
development  of  an  ADS  that  could  match  or  exceed  previous  designs. 

In  summary,  the  combined  problem  that  users,  developers  and  researchers  have  is 
that  there  is  the  need  for  a  proven,  reliable  method  to  distribute  rapidly,  responsively  and 
efficiently  physical  items  from  one  location  to  another  at  potentially  medium  to  long 
ranges  while  incurring  no  additional  threat  from  hostile  forces. 
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c. 


STAKEHOLDER  ANALYSIS 


A  more  thorough  investigation  of  the  applicable  stakeholders,  their  effective 
needs  and  concerns  is  shown  in  Table  2.  As  the  author’s  updated  version  of  the 
Snowflake  was  not  designed  for  a  particular  customer,  the  interests  of  the  stakeholders 
represented  are  generalizations  only,  based  on  information  collected  from  various 
unclassified  sources,  primarily  the  ONR  AACUS  CONOPS  (ONR  2012,  3-4).  Various 
humanitarian  aid  and  non-governmental  organizations  (NGOs)  are  also  potential 
customers  interested  in  the  development  of  micro-light  PADSs.  Additionally,  the  author’s 
needs  are  included  with  the  NPS  needs,  as  it  is  significant  to  highlight  that  successful 
research  and  development  are  still  required  to  develop  solutions  targeting  the  original 
problem  statement. 


Table  2.  Micro-Light  PADS  Stakeholder  and  Needs  Analysis 


Stakeholder 

Type 

Need 

Want 

Concern 

ONR 

Current 

Research  and 
technological 
development  of 
solutions  to  long-term 
capability  shortfalls 

Technology  that  can 
provide  benefit  and 
utility  for  additional 
capability  shortfalls 

Solutions  are  too 
specific  and  fail  to 
address  the  core 
problem  statement 

USMC 

Current 

Dispersal  of  time 
critical  logistic  support 
to  dispersed  units 

Autonomous  delivery 
and  the  ability  to  extract 
wounded  military 
personnel 

Likely  operational 
environment  includes 
hostile  threats.  PADSs 
must  be  supporting 
units,  not  units 
supporting  PADSs. 

NPS 

Current 

Suitable  platform  for 
research  and 
development 

Low-cost  with  minimal 
complexity  and  the 
ability  to  work  with 
non-specialized 
equipment 

Platform  and  results 
must  be  easily 
transferrable 

NGO 

Potential 

Rapid  dispersal  of 
logistics  to  specific 
locations, 

Long  range, 

inexpensive  and  reliable 

Must  be  more  suitable 
in  terms  of  cost  or 
simplicity  than  existing 
alternatives 

USN 

Potential 

Dispersal  of  logistics  to 
mobile  platform 

Rapid,  long  range 
distribution  at  sea  with 
minimal  operational 
impact 

Must  be  more  suitable 
in  terms  of  cost  or 
simplicity  than  existing 
alternatives 
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D.  DESIGN  CRITERIA 


In  re-designing  the  Snowflake,  the  author  considered  the  factors  shown  in 
Figure  10  contrasted  with  some  of  the  design  considerations  required  to  field  the 
operational  system  shown  in  Figure  11.  The  blue  design  considerations  are  common 
between  the  NPS  Snowflake  and  an  operationally  fielded  micro-light  PADS.  The 
considerations  shown  in  green  are  unique  to  an  operationally  fielded  system.  Conceptual 
and  preliminary  system  design  considerations  for  a  research-focused  system  in 
development  differ  from  those  of  an  operationally  fielded  system.  More  significantly,  the 
prioritization  of  these  design  considerations,  regardless  of  the  system’s  objective,  evolves 
during  development. 


Figure  10.  System  Design  Considerations  for  Research  Focused  NPS 
Snowflake.  Adapted  from  Blanchard  and  Fabrycky  (2011). 
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Figure  1 1 .  System  Design  Considerations  for  Operationally  Fielded  Micro- 
Light  PADSs.  Adapted  from  Blanchard  and  Fabrycky  (201 1). 

Table  3  presents  the  shifting  emphasis  between  a  research-focused  developmental 
design  and  the  design  considerations  associated  with  an  evolved  system.  This  fluidity  of 
design  has  potential  peril  in  that  the  developmental  design  can  begin  to  migrate  away 
from  the  original  problem  statement  and  effective  stakeholder  needs. 
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Table  3.  Contrast  of  Design  Consideration  Emphasis  During  Preliminary 
Design  for  Research  Focused  NPS  Snowflake  and  Operationally  Fielded 

Micro-Light  PADSs 


Design 

Consideration 

Research-Focused  NPS  Snowflake 

Operationally  Fielded  Micro-Light 
PADSs 

Flexibility 

Support  diverse  research  and  testing 
objectives  as  they  are  developed 

Support  customer  needs  and  wants  as 
they  evolve 

Interoperability 

Interoperable  with  available  test 
platforms 

Interoperable  with  all  fielded  systems 

Safety 

Controlled  environment  with  trained 

users 

Potentially  hostile  and  adversarial 
environment  with  minimally  trained 
users 

Reliability/ 

Maintainability 

Adequate  to  support  multiple  scientific 
experiments.  Failures  are  expected. 

Customer  expects  high  reliability. 

Impact  of  failure  can  be  catastrophic. 

Technical  Feasibility 

Must  be  accomplished  by  two-person 
team  within  6-9  months 

Greater  opportunity  for  technical 
advancement  and  solutions 

Consistency 

Consistent  data  collection  is  paramount 
in  development 

Consistent  performance  is  paramount  in 
operation 

Supportability 

Limited  support  during  testing  at  Camp 
Roberts 

Potential  requirement  to  be  supported 
in  austere  locations 

Human  Factors 

Only  1-2  specialized  operators 

Must  be  able  to  work  with  5-95% 
percentile  operator 

Maintainability 

Must  be  able  to  conduct  multiple 
experiments  in  short  period  of  time 

Potential  to  be  single  use  only 

Affordability/ 

Profitability 

Research  budget  with  no  specialized 
equipment 

Potential  economy  of  scale,  but 
profitability  is  significantly  weighted 
priority 

Functionality 

Flexible  for  various  experiments 

Flexible  for  various  missions 

Producibility 

Short  timeline  with  minimal  specialized 
equipment 

Production  costs  are  concern,  but 
unknown  in  development 

Product  Quality 

Not  a  concern 

Customer  demands  high  and  consistent 
product  quality 

Recyclability/ 

Disposability 

Not  a  concern 

Potential  to  be  a  significant  concern  as 
the  units  may  not  be  recovered 

Environmental 

Sustainability 

Not  a  concern 

Warrants  significant  attention  based  on 
customer  needs 

Social/Political 

Feasibility 

Not  a  concern 

Warrants  significant  attention  based  on 
customer  needs 

The  author’s  initial  design  considerations  matched  those  of  the  operationally 
fielded  design  but  migrated  as  the  objectives  and  effective  stakeholder  needs  evolved. 
Effectively,  the  author  became  the  primary  stakeholder,  with  successful  thesis  completion 
emerging  as  the  primary  problem  statement.  To  support  this  objective,  the  emphasis  on 
data  collection  and  failure  mode  correction  emerged  as  paramount. 
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E.  ARCHITECTURE  DECISIONS 


As  the  emphasis  for  design  considerations  evolved  during  the  conceptual  and 
preliminary  phases,  the  architecture  was  designed  to  incorporate  a  high  degree  of 
flexibility,  modularity,  maintainability  and  consistency.  Since  flight  experimentation  for 
the  NPS  Snowflake  needed  to  be  completed  in  one-to-two  day  periods  of  data  collection 
and  initial  designs  exhibited  low  component  experimental  survivability,  the  author 
emphasized  modularity  within  the  design.  As  guidance  computers,  control  actuators, 
parachutes  and  telemetry  components  frequently  did  not  survive  even  the  reduced  impact 
forces  at  landing,  the  design  prioritized  the  ability  to  replace  damaged  components  with  a 
minimal  amount  of  down  time.  Additionally,  there  were  several  ram-air  parachute 
designs  that  would  be  tested,  so  the  design  incorporated  the  modular  concept  to  facilitate 
parachutes  that  could  readily  be  transferred  and  repacked  in  the  field. 

In  addition  to  the  high  degree  of  component  modularity,  initial  designs  required 
an  architecture  that  could  support  flexibility.  Prototype  systems  are  likely  to  change 
significantly  and  eventually  converge  on  a  preferred  design.  Working  with  a  limited 
timeline  and  budget,  the  author  desired  a  flexible  architecture  that  could  support  multiple 
design  changes  and  adaptations. 

F.  OPERATIONAL  CONCEPT 

The  operational  concept  for  employment  of  precision  airdrop  combat  delivery 
missions  is  shown  in  the  Department  of  Defense  Architecture  Framework  (DODAF) 
Operational  View  (OV)  shown  in  Figure  12.  This  does  not  represent  all  of  the  potential 
uses  for  PADSs,  as  it  is  specific  for  a  combat  logistical  delivery  over  land.  However,  the 
core  concept  is  that  there  is  a  demand  to  deliver  something  to  a  remote  location,  within  a 
certain  threshold  for  accuracy.  The  exact  composition  of  the  payload  and  the  intended 
coordinates  are  transmitted  to  a  command  and  control  node  along  with  an  aggregated 
weather  and  winds  estimate  to  compute  an  optimized  CARP.  In  general,  PADSs  can  vary 
from  supporting  long-term  strategic  objectives  to  supporting  small-scale  urgent  resupply 
to  troops  in  contact.  Additionally,  though  the  OV-1  depicts  a  large  fixed-wing  cargo 
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aircraft,  the  operational  concept  is  equally  valid  for  all  types  of  aerial  delivery  platforms, 
including  UASs. 


Comm 


GPS 


Communications/Data  Paths 

■  ■■■■•  Position  Feedback 

(upon  impact  with  ground) 

GPS  Position  Data 
•  •■■■■  C2/Wx/Drop  Zone  Data 


Airdropped 

Payloads 


Figure  12.  Precision  Airdrop  Combat  Delivery  Missions  (OV-1).  Source: 

Benney  et  al.  (2005b). 


G.  FUNCTIONAL  ANALYSIS 

Blanchard  and  Fabrycky  state  that  functional  analysis  in  the  early  conceptual  and 
preliminary  design  phases  allows  the  engineer  to  generate  detailed  design  criteria,  as  well 
as  to  identify  the  resources  required.  (2011,  86)  With  consideration  to  the  complexity  of  a 
prototype  PADS,  the  author  derived  and  continually  adjusted  a  functional  hierarchy  and 
the  associated  descriptions  of  the  functions. 
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1.  Functional  Hierarchy 

A  functional  analysis  was  performed  by  the  author  to  decompose  the  mission  of 
preforming  the  aerial  resupply  mission.  The  author’s  intent  was  to  decompose  the  core 
functions  required  to  complete  the  mission.  Along  with  the  core  mission  functional 
hierarchy  shown  in  Figure  13,  the  secondary  mission  of  performing  design 
experimentation  is  evident.  Initial  PADS  prototypes  were  constructed  to  perform  the  core 
mission,  but  significant  adjustments  were  required  to  support  design  development  and 
testing.  The  additional  functions,  shown  in  green  in  Figure  13,  were  unique  functions 
incorporated  into  the  Snowflake  ADS  simply  to  support  development,  but  the  author  did 
feel  it  was  significant  to  highlight  the  degree  to  which  initial  designs  effectively  had 
missions  of  their  own.  These  functions  were  derived  from  design  requirements  that  were 
generated  through  discovery  during  testing. 

Application  of  the  systems  engineering  methodology  through  functional  analysis 
proved  extremely  useful.  Rather  than  focus  on  component  specific  solutions  to  problems 
encountered  during  development,  the  author  frequently  returned  to  the  first  and  second 
level  functional  decomposition  to  determine  the  root  function  being  performed.  This 
functional  analysis  was  effective  in  focusing  the  design  effort  toward  the  what  needed  to  be 
accomplished,  versus  the  how  it  was  to  be  achieved  (Blanchard  and  Fabrycky  2011,  86). 
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Figure  13.  Functional  Hierarchy  of  Two  PADS  Missions 
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2.  Description  of  Functions 

Each  of  the  functions  that  the  PADS  was  designed  to  perform  is  described  in 
Table  4.  Only  the  first  and  second  level  functions  are  shown,  and  though  several  state 
functions  such  as  “to  be  affordable,”  “to  be  flexible”  or  “to  be  supportable”  were 
significant  concerns  during  design,  they  are  not  characterized  as  functions  that  the  PADS 
would  perform. 


Table  4.  Description  of  Functions 


Number 

Function 

Description 

1 

Transit 

Transit  from  launch  location  to  CARP 

1.1 

Attach 

Secure  to  launch  platform  (significant  for  externally  mounted 
PADSs  on  UAVs) 

1.2 

Contain  Parachute 

Contain  parachute  from  launch  to  CARP  (significant  for  externally 
mounted  PADSs) 

2 

Separate 

Safe  separation  of  PADS  from  launch  platform  which  does  not 
damage  or  place  either  component  at  risk 

2.1 

Release  from  Launch 
Platform 

Release  from  launch  platform  with  required  arming  and  release 
functions  performed 

2.2 

Deploy  Parachute 

Actuate  release  mechanism  allowing  parachute  bag  to  open  and 
parachute  to  deploy 

3 

Control 

Execute  control  of  the  PADS  through  steering  line  retraction 

3.1 

Sense  Motion 

Measure  and  record  current  PADS  attitude  and  acceleration 

3.2 

Actuate  Steering  Lines 

Release  and  retract  opposing  steering  lines  during  flight 

3.3 

Dampen  Oscillation 

Control  and  reduce  PADS  roll,  pitch,  yaw  oscillations 

3.4 

Respond  to  Operator 
Command 

Respond  to  operator  input  during  PADS  flight  by  non-specified 
means 

4 

Navigate 

Translate  from  PADS  present  position  to  desired  IP 

4.1 

Determine  Current 
Position 

Measure  PADS  current  location  and  altitude 

4.2 

Estimate  Winds 

Measure/calculate  winds  during  descent  profile 

4.3 

Maneuver  to  IP 

Based  on  present  positon  and  predicted  wind,  adjust  profile  to 
desired  IP 

5 

Communicate 

Communicate  with  operator 

5.1 

Receive  Target 

Location 

Accept  input  of  desired  target  location 

5.2 

Receive  Navigation 
Information 

Accept  input  of  present  position  and  altitude 

5.3 

Transmit  Wind 
Measurements 

Transmit  calculated  wind  estimation  for  subsequent  PADSs 

5.4 

Transmit  Test  Data 

Transmit  compiled  status  and  collected  data  for  experimental 
analysis 

6 

Land 

Impact  surface 

6.1 

Flare 

Maneuver  control  surfaces  to  reduce  vertical  speed  on  landing 

6.2 

Survive 

Withstand  surface  impact  for  subsequent  use/experimentation 

6.3 

Preserve  Test  Data 

Preserve  all  flight  test  data  for  continues  developmental  testing 
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H.  SUMMARY 


This  chapter  provided  a  summary  of  the  technical  activities  included  in  the 
conceptual  and  preliminary  design  phases.  It  also  defined  the  core  problem  that  PADSs 
are  designed  to  resolve  and  subsequently  identified  the  basic  functions  that  the  system 
needs  to  execute  in  both  an  operational  and  experimental  settings.  The  needs,  wants  and 
concerns  of  several  stakeholders  were  detailed,  as  well  as  the  design  criteria  that  drove 
conceptual  design.  Points  of  contrast  between  operational  and  experimental  system 
design  criteria  were  highlighted.  The  chapter  included  several  architecture  decisions  and 
described  the  influence  of  shifting  design  considerations  on  the  architectural 
development.  The  operational  concept  for  PADS  employment  was  discussed  and  a 
functional  analysis  was  specified.  The  application  of  the  described  systems  engineering 
methodology  to  the  development  of  the  prototype  Snowflake  ADS  is  detailed  in  the 
following  chapter. 
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IV.  BLIZZARD  SYSTEM  COMPONENTS  AND  SNOWFLAKE 

ADS  DESIGN 


In  order  to  conduct  initial  and  preliminary  design  experimentation,  the  updated 
Blizzard  system  consisted  of  the  following  four  components:  an  Arcturus  UAV,  a 
modular  AGU,  a  series  of  ram-air  parachutes  and  the  release/separation  interface  between 
the  launch  platform  and  the  AGU.  All  of  the  components  were  required  to  perform  the 
functions  necessary  to  conduct  a  PADS  experiment,  and  each  is  described  in  detail  in  this 
chapter.  As  initial  and  preliminary  design  is  a  highly  iterative  process,  several  of  the  early 
and  intermediate  designs  have  been  omitted,  except  as  noted.  The  Snowflake  ADS  design 
incorporated  a  high  degree  of  modularity  and  flexibility  in  order  to  facilitate  controlled 
changes  to  each  of  the  components  to  correct  expected  and  unexpected  failure  modes. 
Additionally,  a  comparison  of  the  flight  control  dynamics  between  a  conventional  fixed- 
wing  platform  and  the  flight  control  dynamics  of  a  ram-air  parachute  are  described 
because  the  limitations  presented  proved  significant  in  the  construction  and 
implementation  of  a  functional  ADS. 

A.  ARCTURUS  T-20  AND  JUMP  20 

The  Snowflake  ADS  was  designed  to  maximize  compatibility  with  any  available 
UAV  launch  platform  that  could  both  support  testing  and  potentially  serve  as  a 
component  in  an  operational  Blizzard  AADS.  Fortunately,  two  versions  of  UAVs  were 
available  and  used  to  support  flight-testing  at  McMillan  Airfield,  Camp  Roberts,  CA:  the 
fixed-wing  Arcturus  T-20  and  a  more  advanced  VTOL  version  called  the  JUMP  20. 
Specifications  for  each  of  the  UAVs  are  shown  in  Table  5.  During  testing,  the  author 
would  generally  receive  two-to-three-week’s  notice  of  which  type  of  UAV  would  be 
available,  requiring  the  Snowflake  ADS  to  be  designed  to  support  compatibility  with 
diverse  launch  platforms  with  minimal  modification. 
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Table  5.  Comparison  of  Arcturus  UAV  Specifications  Adapted  from 
Arcturus  UAV  (2015a  and  2015b). 


Specification 

T-20 

JUMP  20 

Type 

Conventional  using  pneumatic 
catapult  launcher 

Vertical  Takeoff  and  Fanding 
(VTOF) 

Airframe 

Airframe  monocoque  composite 

Airframe  monocoque  composite 

Wing  Span 

17’  6” 

18’  6” 

Length 

9’  5” 

9’  5” 

Engine 

190cc  4  Stroke 

190cc  4  Stroke 

Fuel 

MOGAS 

MOGAS 

Typical  MTOW 

185  pounds 

210  pounds 

Typical  Max  Speed 

75  kts 

72  kts 

Endurance 

10-20  hours  (payload  dependent) 

9-16  hours  (payload  dependent) 

Payload  Capacity 

75  pounds 

60  pounds 

Main  Payload  Bay 

4,100  cubic  inches 

4,100  cubic  inches 

Rated  Ceiling 

15000’  (proven  to  25000’)  MSL 

15000’ MSF 

Guidance 

Full  autonomous  operation,  launch  to 
land 

Full  autonomous  operation,  launch  to 
land 

Characteristics 

Flight  and  recovery  under  austere 
conditions 

Flight  and  recovery  under  austere 
conditions 

1.  T-20 

The  T-20  is  a  fixed-wing  fully  autonomous  UAV  which  had  previously  conducted 
research  support  with  the  Blizzard  AADS  and  is  shown  in  Figure  14.  The  T-20  offers 
slightly  greater  range,  altitude,  endurance  and  payload  capacity  when  compared  to  the 
JUMP  20.  However,  it  requires  a  relatively  large  pneumatic  catapult  for  launch  as  well  as 
a  prepared  surface  for  landing.  The  T-20  supported  Snowflake  payload  deployment  from 
either  wing  as  well  as  conducting  multiple  deployments  during  the  same  flight.  The  T-20 
could  reach  launch  altitude  within  roughly  five  minutes  and  required  only  minutes  to 
conduct  post-flight  maintenance  inspections  and  subsequent  pre-flight  and  startup 
procedures.  As  such,  the  T-20  could  support  close  to  two  experimental  flights  per  hour. 
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Figure  14.  Arcturus  Fixed-Wing  Version  (T-20).  Source:  Arcturus  UAV 

(2015a). 


2.  JUMP  20 

The  JUMP  20,  shown  in  Figure  15,  is  a  more  advanced  version  of  the  T-20  which 
is  designed  to  conduct  VTOL  operations.  The  VTOL  capability  offers  a  significant 
enhancement  for  shipboard  operations  where  launch  and  land  spaces  are  limited.  The 
JUMP  20  does  have  a  slightly  reduced  range  and  shorter  endurance  when  compared  to  a 
conventional  fixed-wing  UAV.  As  it  did  not  require  a  pneumatic  catapult,  the  JUMP  20 
had  centerline  fuselage  mounting  stations  in  addition  to  the  under  wing  stations. 
Unfortunately,  its  payload  capacity  is  slightly  smaller  than  the  T-20,  which  would 
decrease  its  operational  utility  slightly.  Additionally,  when  conducting  flight 
experimentation,  the  JUMP  20  required  significantly  longer  to  reach  an  operational 
altitude  and  the  time  between  launches  was  roughly  twice  that  of  the  T-20.  The  post- 
flight  electric  charging  requirement  reduced  the  availability  of  the  JUMP  20  by  roughly 
50%  as  compared  to  the  T-20. 
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Figure  15.  Arcturus  VTOL  Version  (JUMP  20).  Source:  Arcturus  UAV 

(2015b). 


3.  Integration 

Despite  efforts  to  construct  a  Snowflake  ADS  that  required  minimum  integration 
with  the  launch  platform,  the  author  remained  subject  to  some  distinctive  differences  in 
operation  between  a  catapult-launched  fixed-wing  UAV  and  a  VTOL  UAV.  Launches  from 
a  T-20  subjected  the  Snowflake  to  an  acceleration  of  approximately  5  Gs.  As  such,  the 
internal  components  needed  to  be  tightly  secured  and  the  external  parachute  container  needed 
to  be  sufficiently  robust  to  prevent  parachute  release  shortly  following  launch.  In  contrast,  the 
VTOL  JUMP  20  had  a  very  smooth  and  controlled  launch  acceleration  of  approximately  1.2 
Gs,  which  did  not  stress  the  parachute  container  on  takeoff. 

Though  the  JUMP  20  did  not  subject  the  Snowflake  to  the  stress  of  a  catapult 
launch,  there  was  a  much  smaller  threshold  for  harmful  interference  between  the  UAV 
and  the  Snowflake  ADS.  During  the  takeoff,  landing  and  transition  to  and  from  forward 
flight,  the  vortices  generated  by  the  four  rotors  created  highly  turbulent  airflow  around 
the  wing  and  the  Snowflake.  As  such,  the  mounting  hardware,  static  lines  and  parachute 
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deployment  lanyards  all  had  to  be  short  enough  to  prevent  harmful  interference  with  the 
rotors.  The  relatively  tight  tolerances  for  mounting  hardware  presented  a  small,  but 
manageable  integration  challenge  between  the  two  systems,  but  these  were  necessary 
precautions  to  prevent  an  increased  risk  of  a  catastrophic  failure. 

B.  AUTOMATED  GUIDANCE  UNIT 

The  Snowflake  ADS  was  composed  of  three  elements:  an  AGU,  a  parachute,  and 
the  release/parachute  deployment  mechanism.  Various  iterations  of  the  AGU  were 
constructed  during  development,  with  the  preponderance  of  effort  focused  on  two 
different  flight  controllers  and  a  power  distribution  design  that  would  facilitate 
development,  testing  and  repeated  experimentation.  The  following  section  details  the 
specifics  and  implementation  of  each  type  of  flight  controller,  as  well  as  the  final  design 
for  a  power  distribution  bus. 

1.  Prototype  with  Pixhawk  Flight  Controller 

The  Pixhawk  flight  controller  from  3D  Robotics,  as  shown  in  Figure  16,  was  initially 
chosen  as  a  low-cost  automated  guidance  unit.  The  Pixhawk  is  a  commercially  available, 
customizable,  navigation  and  control  platform  used  widely  through  the  hobby  and 
commercial  UAV  industry.  The  Pixhawk  offers  a  three-axis  gyroscope,  a  three-axis 
accelerometer/magnetometer,  an  onboard  barometer  for  detecting  altitude  changes  as  well  as 
integration  for  an  external  GPS  receiver.  The  author  also  utilized  the  Pixhawk’ s  radio  control 
integration  to  assist  in  developmental  testing  and  to  conduct  controlled  flight  experiments. 
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Figure  16.  Pixhawk  Flight  Computer  and  Installation  in  Prototype  Snowflake 

ADS 

In  addition  to  the  previously  described  features,  the  Pixhawk  was  designed  to  be 
configurable  for  a  variety  of  UAV  platforms,  to  include  multiple  types  of  copters,  ranging 
from  one  to  eight  blades,  land-based  roving  vehicles  and  conventional  fixed-wing 
aircraft.  Working  in  conjunction  with  Lieutenant  Commander  Matthew  O’ Brian,  the 
author  determined  that  the  Pixhawk  would  be  able  to  provide  satisfactory  guidance  and 
control  for  the  Snowflake  ADS  at  a  sufficiently  low-cost  that  operational  employment  in 
a  one-time-use  scenario  would  prove  feasible. 

The  prototype  AGU  also  included  two  Tumigy  TGY-6114MD  digital  sail  winch 
servos  secured  to  a  custom-built  mounting  board  made  of  G-10  glass  epoxy  composite 
laminate.  Early  designs  utilized  commercially  available  polycarbonate  sheets,  but  the 
polycarbonate  was  not  sufficiently  strong  to  support  all  components  under  stress  or  to 
absorb  the  landing  shock  associated  with  an  ADS  touchdown.  The  Pixhawk  and  the 
servos  were  powered  using  a  2200mAh  7.4V  2-cell  lithium  polymer  battery,  which  would 
provide  adequate  power  for  a  roughly  20-minute  flight.  The  author  opted  not  to  use  a 
larger  battery,  theorizing  that  weight  conservation  in  design  would  provide  additional 

flexibility  throughout  development  and  ballast  could  be  added  if  required.  Finally,  the 
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design  included  a  HobbyKing  HKU5  5V/5A  battery  eliminator  circuit  (BEC)  to  isolate 
servo  power  from  the  Pixhawk  guidance  unit. 

Externally,  the  author  intended  to  inherit  the  parachute  bag  from  the  previous 
Snowflake  ADS,  but  initial  flight-testing  proved  nearly  catastrophic  as  detailed  in 
Chapter  V.  Following  the  initial  flight  tests,  the  parachute  bag  was  redesigned  by  a  small 
team  consisting  of  the  author  and  Major  Alan  Stephens  as  an  element  of  the 
SE3201/SE3202/SE3203  design  project  course.  In  addition  to  correcting  a  potentially 
hazardous  failure  mode,  the  updated  design  was  created  to  support  the  flexibility  design 
consideration.  The  updated  parachute  bags,  shown  in  Figure  17,  would  accommodate 
diverse  parachute  sizes  and  shapes  as  well  as  multiple  release  methods.  As  a  final  design 
had  not  been  determined  yet,  the  parachute  bags  were  primarily  designed  to  support 
repeated  flight  experimentation.  The  author  planned  to  create  a  more  fit-for-purpose 
design  as  development  converged  on  a  preferred  parachute  size,  type  and  release  method. 
Unfortunately,  the  design  did  not  converge  on  a  single  parachute  design  and  release 
sequence  until  after  the  author’s  final  flight-testing  opportunity  at  McMillan  Airfield  in 
February  2016. 


Figure  17.  Snowflake  ADS  Parachute  Bag 


2.  X-Monkey  Flight  Controller 

Following  some  of  the  experiments  detailed  in  Chapter  V,  the  design  of  the  AGU 
evolved  to  incorporate  a  new  flight  controller  more  suitable  for  guidance,  control  and 
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experimentation.  The  X-Monkey  from  Ryan  Mechatronics  is  a  similar  autopilot  as  the 
previously  described  Pixhawk,  with  three-axis  gyroscopes,  three-axis  accelerometers  and 
magnetometers  and  an  integrated  GPS.  The  Pixhawk  and  X-Monkey  are  similar  in  terms 
of  the  function  of  the  internal  components,  and  the  cost  is  roughly  comparable.  In 
selecting  the  Pixhawk,  the  author  hoped  to  incorporate  COTS  technology  with  a 
minimum  amount  of  modification  to  deliver  the  functions  required  of  an  AGU  in  a 
PADS.  Unfortunately,  the  author  struggled  with  the  requirement  to  modify  the  Pixhawk 
with  little  to  no  technical  support  available.  As  such,  the  author  converted  to  a  design 
utilizing  the  X-Monkey.  The  X-Monkey  offered  less  performance  out  of  the  box,  but 
offered  a  much  more  open  software  development  platform  suitable  for  modification  to 
autonomous  parachute  control.  It  also  had  a  more  proven  history  of  success  in  supporting 
scientific  experimentation.  Most  importantly,  the  manufacturer  was  extremely  responsive 
to  technical  support  requests  and  provided  significant  assistance  in  the  adaptation  of 
control  and  guidance  algorithms. 

In  addition  to  the  X-Monkey  autopilot,  the  final  prototype  incorporated  a  Digi 
Zigbee  802.15.4  Radio  module,  which  could  be  paired  with  the  X-Monkey  graphical  user 
interface  (GUI)  for  command  and  data  transmission.  Lastly,  the  final  prototype  was 
updated  to  include  a  20-amp  BEC/voltage  regulator  from  Castle  Creations.  The  internal 
components  of  the  final  Snowflake  prototype,  including  the  installed  X-Monkey,  are 
shown  in  Figure  18. 
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Figure  18.  X-Monkey  Flight  Computer  and  Installation  in  Final  Prototype 
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3.  Power  Supply  and  Distribution 

The  power  supply  and  distribution  sub-system  for  the  Snowflake  AGU  consisted 
of  relatively  simple  COTS  components,  but  required  some  adjustment  to  eliminate  the 
need  for  additional  batteries  isolating  the  autopilot.  Since  modularity  and  maintainability 
were  principal  design  considerations,  the  author  created  and  maintained  a  design  that  could 
provide  the  necessary  power  to  each  component,  offer  limited  electrical  isolation  of  the 
more  sensitive  components  and  still  be  simple  enough  that  the  wiring  harnesses  could  be 
exchanged  in  the  field  with  minimal  down  time.  An  operationally  suitable  Snowflake  AGU 
would  likely  have  a  bit  more  fit-for-purpose  design  elements,  but  the  schematic  shown  in 
Figure  19  supported  Snowflake  flight  control  as  well  as  data  collection. 

As  a  Snowflake  ADS  flight  experiment  was  roughly  20  minutes  from  power-up  to 
landing,  the  relatively  small  7.4-volt  battery  provided  sufficient  power  to  the  control  line 
servos,  but  a  20-amp  capacity  BEC  was  required  to  prevent  the  output  from  dropping 
below  the  five  volts  necessary  to  power  the  X-Monkey  and  to  continue  data  recording. 
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Initial  designs  with  a  smaller  capacity  BEC  occasionally  caused  the  input  power  to  the  X- 
Monkey  to  drop  below  five  volts  and  subsequently  would  trigger  a  reset.  This  reset  would 
cause  the  X-Monkey  to  stop  recording  flight  data  for  approximately  five  seconds  and 
would  reset  the  servo  output  commands  to  a  neutral  condition.  The  transient  current 
spikes  were  caused  by  rapid  reversals  to  the  control  lines  or  stalled  conditions  during 
parachute  opening  malfunctions. 


Figure  19.  Electrical  Power  Distribution  for  Snowflake  ADS 


C.  RAM-AIR  PARACHUTE  SPECIFICATIONS 

Early  design  objectives  were  to  incorporate  a  variety  of  available  ram-air 
parachutes  in  order  to  evaluate  which  offered  the  best  maneuverability  and  consistency. 
Unfortunately,  several  of  the  ram-air  parachutes  did  not  perform  with  sufficient  reliability 
to  asses  and  improve  the  design.  As  such,  the  implementation  of  each  parachute  is 
described  below,  with  the  final  design  converging  on  the  rectangular  ram-air  parachute 
due  to  its  relatively  high  build  quality  and  consistent  flight  performance. 

1.  Elliptical  Ram- Air  Parachute 

Initial  designs  for  the  updated  Snowflake  ADS  were  developed  to  utilize  a 
commercially  available  elliptical  ram-air  parachute  as  shown  in  Figure  20.  The  elliptical 
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parachutes  were  a  relatively  low-cost  design  and  offered  the  potential  for  enhanced 
maneuverability  over  the  rectangular  parachutes  previously  used  in  Snowflake  ADS 
development.  Preliminary  experimentation  indicated  that  parachute  was  approximately 
10  ft2,  though  exact  measurements  were  not  determined.  The  NPS  ADSC  Laboratory  had 
a  good  supply  of  these  elliptical  parachutes,  and  they  were  initially  thought  to  be  suitable 
for  repeated  experimentation.  Initial  testing  of  the  elliptical  parachute  conducted  at  NPS 
on  May  1,  2015,  as  shown  in  Figure  20  demonstrated  positive  results,  but  it  is  significant 
to  note  that  the  tests  were  conducted  with  a  nearly  inflated  parachute  at  release  and  the 
parachute  bag  had  not  been  implemented  yet. 


Figure  20.  Elliptical  Ram- Air  Parachute  Preliminary  Testing  on  May  1,  2015 

2.  Rectangular  Ram-Air  Parachutes 

Rectangular  ram-air  parachutes  were  also  utilized  in  the  design  and 
experimentation  process  and  proved  to  be  significantly  more  reliable  during  flight 
experimentation,  though  they  offered  slightly  reduced  maneuverability.  Experiments 
were  conducted  utilizing  rectangular  ram-air  parachutes  of  two  different  sizes,  as  the 
Snowflake  ADS  was  designed  to  work  with  a  series  of  weight  payloads.  The 

specifications  for  the  rectangular  ram-air  parachutes  used  are  show  in  Figures  21  and  22. 

45 


In  addition  to  their  increased  reliability,  the  rectangular  parachutes  were  easier  to  pack 
and  their  construction  was  of  a  much  higher  quality  than  the  elliptical  parachutes  had. 
Numerous  unsuccessful  attempts  were  made  during  the  research  process  to  procure 
additional  parachutes  of  differing  sizes  and  shapes  to  support  testing.  Parachute 
manufacture  can  be  extremely  expensive  and  the  normally  high  cost  was  compounded  by 
the  fact  that  there  is  presently  very  limited  commercial  utility  for  ram-air  parachutes  of 
this  size. 

Though  these  parachutes  offered  relatively  consistent  performance  during  testing, 
there  is  some  stretching  noted  in  the  lengths  of  the  control  lines  that  can  potentially  affect 
controllability.  Early  testing  of  the  prototype  Snowflake  ADS  included  some  relatively  high 
velocity  openings  that  yielded  a  substantial  opening  shock,  likely  stretching  the  control  and 
support  lines  beyond  their  elastic  limits.  Later  prototypes  had  a  reduced  opening  shock,  but 
the  author  was  not  able  to  repair  the  support  and  control  lines  without  risking  damage  to  the 
only  viable  flight-testing  platforms.  Replacements  were  not  available. 


Rectangular  Ram- Air  Parachute 


46 


Figure  22.  Overhead,  Side  and  Control  Line  Specifications  for  1.5  m2 

Rectangular  Ram- Air  Parachute 


D.  PARACHUTE  DEPLOYMENT  METHODS 

When  the  Snowflake  ADS  was  functionally  decomposed  in  Chapter  III,  one  of  the 
first  level  function  is  “F2.0  To  Separate.”  In  conceptual  design,  the  author  assumed  this 
would  be  a  relatively  simple  function  to  complete  and  it  could  be  accomplished  with 
minimal  complexity.  Through  the  conceptual  and  preliminary  design,  three  types  of 
separation  mechanisms  were  utilized,  starting  with  a  servo-actuated  release,  progressing 
to  a  static  line  release  pin  and  finally  to  a  double  static  line  release. 

1.  Servo-Actuated  Release 

The  initial  prototype  adapted  the  previously  used  design  that  incorporated  a  servo- 
release  pin,  that  could  be  operator  actuated  by  radio  control  or  sensor  actuated  by  the 
autopilot  based  on  a  combination  of  programmed  conditions.  This  design  sequence  is 
shown  graphically  in  Figure  23.  A  servo-actuated  release  was  preferred  initially  because 
it  would  offer  the  capability  for  the  Snowflake  ADS  to  separate  from  the  launch  platform, 
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fall  ballistically  for  a  period  of  time  and  then  open  the  parachute  bag  at  an  optimum 
altitude  or  location  to  minimize  displacement  error  on  landing.  The  author  theorized  that 
the  Snowflake  ADS  could  support  release  from  medium  altitude,  reduce  exposure  time 
by  falling  ballistically  and  then  deploy  the  parachute  at  the  optimum  moment. 
Additionally,  this  design  required  very  limited  integration  with  the  launch  platform.  The 
Snowflake  ADS  could  be  mounted  within  seconds,  and  no  additional  attachments  were 
required  that  would  increase  the  complexity  of  the  design.  Though  these  were  useful 
design  features  for  an  operationally  suitable  system,  they  were  not  required  to  support 
early  testing. 


Remote  servo 
actuation  opens 
bag  and  parachute 
released 

Parachute  bag 
secured  with  servo 
actuated  pin 

Snowflake  released 

Figure  23.  Servo-Actuated  Release  Sequence 


Unfortunately,  on  the  first  two  test  flights,  there  was  a  pre-deployment  of  the 

parachute  immediately  after  the  JUMP  20  executed  its  transition  from  vertical  to  forward 

flight.  Subsequent  post-flight  failure  analysis  determined  there  were  two  potential  failures 

contributing  to  the  pre-deployment:  failure  of  the  parachute  bag  to  contain  the  parachute 

or  premature  actuation  of  the  release  pin  due  to  an  unknown  condition.  As  the  root  cause 

could  not  be  specifically  determined  and  corrected,  the  design  team  implemented  two 

changes  to  eliminate  the  potential  of  a  reoccurrence:  the  parachute  bag  was 

fundamentally  redesigned,  and  the  servo-actuated  release  was  removed  until  the  possible 

transient  behavior  of  the  autopilot  could  be  understood  better. 
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2. 


Static  Release  Pin 


Following  the  initial  prototype,  the  static  release  pin  sequence  shown  in  Figure  24 
was  implemented.  The  parachute  bag  was  kept  closed  by  a  cotter  pin  secured  to  the 
mounting  block  on  the  launch  platform  as  shown  in  Figure  25.  This  design  had  a  slightly 
higher  integration  requirement.  The  Snowflake  had  to  be  mounted  under  the  wing  with  a 
static  line  attached  for  each  flight.  As  the  static  line  remained  underneath  the  launch 
platform  for  the  duration  of  the  flight,  the  author  had  to  consider  any  potentially  harmful 
effects.  Specifically,  on  the  JUMP  20,  the  static  line  was  approximately  12  inches  from 
the  spinning  blade  of  the  aft  lift  fan.  There  was  no  clearance  issue  during  launch  or 
forward  flight;  however,  the  design  could  not  interfere  with  a  high  velocity  propeller 
providing  thrust  during  landing.  With  this  consideration  in  mind,  the  static  line  had  to  be 
sufficiently  long  to  release  the  cotter  pin  on  the  parachute  bag,  but  only  had  about  one 
inch  before  potentially  impacting  the  lift  fan.  This  requirement  added  roughly  five 
minutes  to  the  Snowflake  ADS  loading  sequence  as  the  static  line  had  to  be  measured  and 
confirmed  separately  for  each  Snowflake  ADS. 


released 


Figure  24.  Static  Release  Pin  Sequence 

This  design  served  to  be  robust  and  consistent,  but  following  a  series  of  failures  in 
which  the  parachute  did  not  deploy  from  the  parachute  bag,  the  design  was  adjusted  to 
incorporate  a  second  static  line  tether  to  assist  in  deploying  the  parachute  immediately 
following  release. 
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Figure  25.  Installed  Static  Release  Pin 


3.  Tethered  Deployment 

The  double  static  line  sequence,  shown  in  Figures  26  and  27,  was  implemented  on 
the  final  Snowflake  ADS  prototype  to  address  repeated  failures  cleanly  releasing  and 
deploying  a  parachute.  This  design  removed  the  capability  of  a  servo-actuated  release  and 
could  potentially  limit  the  operational  utility  of  the  system.  The  author  applied  a  systems 
engineering  design  methodology  by  characterizing  the  servo-actuated  release  as  a 
desirable  additional  capability  but  not  worth  the  associated  complexity  cost.  In  order  to 
design  a  prototype  that  could  support  flight  experimentation  and  data  collection,  the 
author  adapted  a  double  static  line  sequence  that  proved  highly  reliable  and  consistent  for 
low  altitude  ADS  flight  profiles. 

Given  that  the  double  static  line  method  was  still  required  to  work  on  both  types 
of  UAVs,  the  requirement  to  minimize  or  eliminate  destructive  flight  interference  was 
present  and  included.  Each  parachute  was  fitted  with  an  approximately  six-foot  lanyard  to 
the  middle  of  the  upper  surface  of  the  ram-air  parachute.  The  lanyard  was  connected  to  a 
12-inch  static  line  that  remained  secured  to  the  mounting  block  on  the  launch  platform. 
The  lanyards  were  connected  by  two  small  rubber  bands  designed  to  break  at 
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approximately  six  pounds  of  force,  roughly  equivalent  to  the  weight  of  a  Snowflake 
ADS.  The  six-foot  lanyard  was  packed  inside  the  parachute  bag  and  would  extend  as  the 
Snowflake  was  released  and  the  parachute  bag  was  opened.  This  second  tether  would 
provide  a  small  but  sufficient  force  to  pull  the  parachute  into  the  airstream  and  initiate 
inflation.  As  the  inflation  was  initiated  so  quickly,  the  opening  shock  was  minimized  as 
well  as  the  chaotic  three-axis  rotation  that  accompanied  the  release.  The  greatly  reduced 
release  dynamics  contributed  significantly  to  consistent  parachute  inflation  suitable  for 
control  and  precise  navigation. 


Figure  26.  Double  Static  Line  Deployment  Sequence 
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Cotter  pin  release  line 
is  on  front  of  Snowflake  ADS 
(not  shown) 


12  Static  lanyard 
(stayed  with  launch  platform) 


Elastic  breakaway 


6’  Lanyard 

(  secured  to  top  of  parachute) 


Figure  27.  Installed  Double  Static  Line 


E.  FLIGHT  CONTROL  DYNAMICS 

The  following  section  details  some  of  the  differences  between  the  flight  control 
dynamics  of  a  fixed-wing  aircraft  and  the  flight  control  dynamics  of  a  ram-air  parachute. 
As  most  COTS  flight  controllers  are  designed  to  work  with  fixed  or  rotary-wing  aircraft, 
it  is  essential  to  detail  the  subtle  differences  which  preclude  flight  control  of  ram-air 
parachute  with  a  fixed-wing  dynamics  without  significant  modification. 

1.  Fixed-Wing  Aircraft 

In  addition  to  the  results  described  in  Chapter  V,  a  comparison  of  the  difference 
between  the  flight  control  dynamics  of  a  fixed-wing  aircraft  and  a  ram-air  parachute  was 
essential  in  the  selection  of  an  appropriate  flight  controller.  When  considering  that  a 
principal  design  consideration  was  the  use  of  COTS  components  because  of  their  low 
initial  cost,  the  author  selected  the  Pixhawk  autopilot  as  being  one  of  the  more  developed 
units  within  the  commercial  autopilot  industry.  It  offered  a  great  deal  of  customizability 
for  use  in  roving  land  vehicles,  fixed-wing  aircraft  and  multiple  versions  of  copters.  The 
author  expected  to  adapt  a  fixed-wing  profile  for  use  in  the  Snowflake  ADS  as  it  was  the 
most  closely  related. 
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The  control  inputs  and  associated  platform  responses  of  a  fixed-wing  aircraft  are 
shown  in  Figure  28.  Each  control  surface  (ailerons,  elevators  or  rudders)  offers  both  a 
positive  and  negative  control  deflection  to  produce  a  platform  response  (roll,  pitch  or 
yaw).  Though  modem  flight  control  systems  often  optimize  and  integrate  these  control 
surface  deflections,  the  initial  Snowflake  design  was  to  decouple  them  to  develop  a  single 
input  single  output  (SISO)  model  of  the  flight  dynamics  of  each  platform  axis.  The 
Pixhawk  flight  controller  offered  the  ability  to  match  the  control  surfaces  shown,  with 
some  degree  of  customization  to  account  for  control  surface  travel  limitations. 
Additionally,  it  did  offer  modes  that  utilized  elevons  to  control  concurrently  both  the  roll 
and  the  pitch.  Through  experimentation,  it  proved  extremely  difficult  to  disable  or 
minimize  the  aileron/elevon  roll  commands. 


Control  Surface  Platform 

Deflection  Response 
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Using  Rudder 


Right  Aileron  Travel:  s 

(Side  View) 
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Figure  28.  Description  of  Flight  Control  Inputs  and  Response  of  Fixed-Wing 

Aircraft 


2.  Ram- Air  Parachute 

In  contrast  to  the  fixed-wing  flight  dynamics,  the  flight  control  input  to  platform 
response  of  the  ram-air  parachute  is  shown  in  Figure  29.  It  is  significant  to  highlight  that 
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though  controlling  the  pitch  and  roll  of  a  guided  ram-air  parachute  is  still  possible,  the 
principal  concern  for  initial  design  was  maneuver  about  the  perpendicular  axis  through 
yaw  control  in  order  to  execute  autonomous  navigation.  Unfortunately,  the  ram-air 
parachute  does  not  offer  a  bi-directional  platform  response  associated  with  bi-directional 
control  surface  deflection.  Since  the  control  lines  can  only  be  retracted,  there  is  no  way  to 
cause  a  negative  control  surface  deflection  on  the  parachute.  Consequently,  the  two 
control  lines  had  to  oppose  each  other,  with  each  providing  independent  positive  control 
deflection  only. 


Platform 

Response 

None 


Positive  Yaw 


None 


Negative  Yaw 


Perpendicular  Axis: 

Yaw  Using  Trailing  Edge  Flap 

Figure  29.  Description  of  Flight  Control  Inputs  and  Response  of  Ram- Air 

Parachute 


The  Snowflake  ADS  could  also  be  expected  to  require  pitch  control  in  an  effort  to 
execute  a  terminal  maneuver  to  minimize  descent  rate  just  prior  to  touchdown.  This 
platform  pitch  could  be  accomplished  with  a  concurrent  positive  control  surface 
deflection.  In  contrast  to  the  yaw  control,  which  required  opposing  control  surface 
deflections,  a  positive  platform  pitch  can  only  be  implemented  by  using  paired  positive 
control  surface  inputs. 
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3.  Challenges  during  AGU  Development 

The  differences  between  control  of  a  fixed-wing  platform  and  a  ram-air  parachute 
proved  to  be  much  more  significant  than  anticipated.  Moreover,  the  operating  platform  of 
the  Pixhawk  did  not  facilitate  easy  creation  of  a  fully  customized  flight  program. 
Unfortunately,  there  was  minimal  customer  support  provided  to  facilitate  this 
customization.  The  Pixhawk  did  not  offer  the  ability  to  offer  opposing  control  line 
retractions  to  control  yaw,  the  ability  to  decouple  roll  control  inputs  to  produce  a  yaw 
response  and  the  ability  to  provide  synchronous  dual  control  line  pitch  control. 

As  a  result  of  these  limitations,  the  author,  in  conjunction  with  Lieutenant 
Commander  O’ Brian,  opted  to  switch  to  the  X-Monkey  flight  controller  due  to  its  greater 
customizability  and  the  availability  of  customer  support. 

F.  SUMMARY 

In  this  chapter,  the  conceptual  and  preliminary  design  of  a  Snowflake  ADS  and 
several  additional  components  of  the  Blizzard  AADS  are  described.  The  specifications 
for  the  two  types  of  UAVs  that  were  utilized  in  flight-testing  are  included.  Subsequently, 
several  iterations  and  a  final  prototype  design  are  summarized,  including  the  installation 
and  usage  of  two  types  of  autopilot  computers.  A  description  of  the  final  design  for 
power  distribution  is  detailed,  as  early  iterations  contributed  to  unexpected  failures  in 
testing  and  experimentation.  This  chapter  also  includes  a  description  of  each  type  of  ram 
air  parachute  that  was  tested,  as  well  as  the  three  types  of  UAV/Snowflake  separation 
sequences.  A  comparison  of  the  principles  of  flight  control  dynamics  between  fixed-wing 
platforms  and  a  ram  air  parachute  platform  is  incorporated,  as  it  proved  to  be  a  significant 
challenge  in  the  implementation  of  COTS  technology.  Comprehensive  computer 
simulation  and  flight-test  results  of  the  various  prototypes  are  detailed  in  Chapter  V. 
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V.  COMPUTER  SIMULATIONS  AND  FLIGHT-TEST  RESULTS 


Between  April  6,  2015,  and  February  18,  2016,  65  live  flight  experiments  were 
conducted  at  McMillan  Airfield,  Camp  Roberts,  CA.  Additionally,  there  was  a  series  of 
lab  experiments  performed  in  the  ADSC  laboratory  at  NPS  before  and  following  the 
February  2016  flight  tests.  This  chapter  details  the  results  of  those  flight  experiments,  as 
well  as  the  associated  laboratory  experiments,  in  preparation  for  planned  flight-testing  in 
May  2016  in  support  of  Lieutenant  Commander  O’Brian’s  continuation  of  the  research 
effort. 

A.  FAILURE  MODES 

This  section  includes  separate  failure  analyses  of  the  three  types  of  parachute 
deployment  methods,  as  well  as  compiled  results  on  the  success  of  both  autopilot 
computers  in  performing  the  data  recording  function.  Though  a  significant  amount  of 
effort  was  placed  on  prior  lab  testing,  the  uncertainty  associated  with  live  flight-testing 
continued  to  reveal  unexpected  weaknesses  in  the  design. 

1.  Parachute  Deployment  Methods 

The  comprehensive  results  presented  in  Figure  30,  show  the  various  design 

iterations  that  the  author  incorporated  during  a  nearly  10-month  period.  Following  the 

nearly  catastrophic  results  of  April  6,  2015,  the  author  converted  from  a  servo-actuated 

release  to  a  static  release  pin  to  simplify  the  design  and  prevent  a  potential  reoccurrence 

of  early  canopy  release.  Once  the  risk  of  a  catastrophic  failure  was  reduced  with  the 

newly  design  parachute  bag,  the  design  emphasis  shifted  toward  remedying  a  consistent 

problem  of  fouled  or  tangled  parachute  releases.  All  flight  tests  from  April  to  June  2015 

included  the  use  of  the  previously  discussed  elliptical  parachute  design,  which  continued 

to  deploy  in  an  unpredictable  fashion,  frequently  including  full  riser  twists,  line-overs  and 

partial  deployments.  Initially,  the  author  theorized  that  variability  in  the  parachute 

packing  technique  was  to  blame  for  the  inconsistent  results  but  subsequently  determined 

that  the  low  manufacturing  quality  of  the  elliptical  parachutes  was  a  more  likely  cause. 

Additionally,  the  elliptical  parachutes  used  cascade  lines  that  were  mounted  laterally 
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across  multiple  cells  rather  than  along  the  seam  of  a  single  rib.  With  only  one  clean  and 
controllable  parachute  release  in  the  first  10  flight  tests,  the  author  transitioned  to  the 
rectangular  parachutes  described  earlier  for  the  August  2015  flight  tests. 


Figure  30.  Failure  Analysis  of  Snowflake  Parachute  Deployment  Methods 


The  results  of  the  August  and  September  2015  flight  tests  were  successful  in  that 
they  demonstrated  a  slight  improvement  in  the  likelihood  of  a  clean  parachute  release 
when  using  the  rectangular  parafoil.  Unfortunately,  the  flight  tests  revealed  a  previously 
unidentified  problem  with  the  parachute  bag  failing  to  open  during  ffeefall.  As 
constructed,  the  design  required  sufficient  drag  to  open  the  parachute  bag  and  release  the 
parachute.  However,  due  to  the  design  changes  incorporated  following  the  April  2015 
tests  to  reduce  the  risk  of  parachute  pre-deployment  during  the  flight  to  release  altitude, 
the  parachute  bag  was  now  unable  to  provide  a  consistent  opening.  The  bag  had  been 
constructed  to  survive  a  roughly  10-minute  flight  to  release  altitude  at  airspeeds 
approaching  50  knots.  Even  when  the  static  release  pin  was  pulled  during  the  release, 
there  was  an  insufficient  drag  force  to  open  the  parachute  bag.  Frequently,  the  Snowflake 
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would  free-fall  for  close  to  1500  feet  before  opening.  When  the  parachute  did  release  at 
these  free-fall  airspeeds,  the  associated  opening  shock  caused  significant  stress  on  the 
internal  components  of  the  Snowflake  as  well  as  on  the  connecting  hardware.  During  the 
August  and  September  2015  flight-testing,  the  parachute  bag  failed  to  open  three  times, 
each  resulting  in  a  ballistic  profile  terminating  in  complete  disintegration  on  impact.  The 
images  shown  in  Figure  3 1  reveal  some  of  the  parachute  malfunctions  that  plagued  the 
single  static  release  pin  implementation.  Of  the  32  flight  tests  conducted  with  the  static 
release  pin  design,  only  seven  yielded  a  parachute  that  was  fully  inflated  and  controllable. 


Rectangular 
Parachute:  Fouled 
Release 


Elliptical 
Parachute:  Full 
Riser  Twist 


Rectangular 
Parachute:  Full 
Riser  Twist 


Rectangular 
Parachute:  Partial 
Inflation 


Figure  31.  Representative  Parachute  Malfunctions  Using  Single  Static  Line 

Release  Pin 


As  a  result  of  the  previously  described  inability  to  separate  from  the  launch 

platform  and  deploy  a  parachute  in  a  manner  supporting  control,  the  double  static  line 

deployment  sequence  was  implemented  during  field  testing  in  September  2015.  The 
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sequence  did  have  a  few  variations  in  development,  but  converged  on  the  design 
discussed  in  Chapter  IV.  Results  for  the  double  static  line  deployment  sequence 
demonstrated  consistent  performance  by  yielding  a  parachute  deemed  suitable  for  control 
in  29  of  31  flight  experiments.  Additionally,  the  two  failures  of  the  double  static  line 
sequence  were  fouled  releases  not  representing  the  hazardous  conditions  produced  by 
previous  designs. 


Figure  32.  Representative  Successful  Parachute  Inflations  Using  Double 

Static  Line  Deployment  Sequence 


2.  Support  for  Experimental  Data  Collection 

Given  that  the  parachute  sequence  had  begun  to  demonstrate  relatively  consistent 
and  successful  results,  the  author’s  design  emphasis  began  to  shift  to  analysis  of  the  data 
being  collected  by  the  Pixhawk  autopilot  in  September  and  December  2015.  As  shown  in 
Table  6  and  Figure  33,  the  Pixhawk  autopilot  proved  unreliable  in  sensing,  preserving 
and  recording  the  experimental  flight  data  required  for  control  and  navigation.  Though 
various  lab  and  flight  experiments  were  attempted,  the  author  was  never  able  to  isolate 
the  fundamental  causes  of  the  failure  to  capture  flight  data.  The  author  determined  that 
the  complex  series  of  sensors  required  to  conduct  a  flight  experiment  needed  to  be 
powered  and  functioning  appropriately  for  the  autopilot  to  remain  armed  and  recording 
data.  The  most  likely  cause  was  repeated  high  magnitude  deceleration,  experienced  on 
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either  ground  impact  or  in  high  velocity  parachute  deployment.  Any  transient  interruption 
in  the  power  supply  or  telemetry  link  could  cause  the  Pixhawk  to  change  flight  modes 
and  negatively  impact  its  ability  to  record  and  preserve  data. 


Table  6.  Summary  of  Autopilot  Data  Collection  Results 


Autopilot 

No  Data  Recorded 

Data  Invalid 

Data  Valid 

Total 

Number 
of  Flights 

%of 

Total 

Number 
of  Flights 

%  of 
Total 

Number  of 
Flights 

%of 

Total 

Pixhawk 

24 

45.3% 

10 

18.9% 

19 

35.8% 

53 

X-Monkey 

0 

0.0% 

0 

0.0% 

12 

100.0% 

12 

Totals 

24 

36.9% 

10 

15.4% 

31 

47.7% 

65 

Figure  33.  Summary  of  Autopilot  Data  Collection  Results 


In  addition  to  the  failure  to  record  useful  data,  the  Pixhawk  was  also  subject  to 

multiple  small  sensor  component  failures  that  would  cause  gross  errors  in  the  information 

being  recorded.  These  failures  were  often  undetectable  during  pre-flight  programming 

They  would  only  manifest  themselves  on  subsequent  data  analysis  revealing  inaccurate 
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magnetic  heading,  altitude  or  GPS  position  information.  As  a  result  of  this  inability  to 
adequately  record  experimental  data,  the  author  determined  it  was  not  suitable  for  use  in 
the  Snowflake  platform  and  replaced  it  with  the  previously  described  X-Monkey  which 
demonstrated  significant  improvement  in  reliability  and  consistency.  In  contrast  to  the 
Pixhawk  recording  valid  data  on  35.8%  of  its  test  flights,  the  X-Monkey  has 
demonstrated  100%  success  in  collecting  and  preserving  flight  data  through  12  flight 
experiments. 

B.  COORDINATE  TRANSFORMATION  AND  FLIGHT  PROFILES 

This  section  details  the  homogeneous  coordinate  transformation  used  to  convert 
the  X-Monkey  autopilot  flight  data  to  a  more  usable  reference  frame,  including  a 
description  on  the  use  of  quaternions.  Additionally,  this  section  includes  samples  of 
sensor  data  from  lab  experiments  as  well  as  representative  flight  data  from  a  controlled 
Snowflake  flight  experiment. 

1.  Coordinate  Transformation 

Positioning  the  X-Monkey  inside  the  Snowflake  required  performing  a  coordinate 
transformation  to  convert  effectively  the  recorded  sensor  data,  which  was  expressed  in 
the  sensor  frame  {.vj,  to  the  body  coordinate  frame  {b}  for  the  Snowflake.  The  rotation 
matrix  ( R )  shown  below  represents  the  orientation  rotation  of  the  X-Monkey  sensor  to  the 
Snowflake  body  frame  in  terms  of  the  Euler  angles  (<p,6,y/)  required  to  rotate  the 
coordinate  frame.  The  Euler  angles  for  the  X-Monkey  to  Snowflake  rotation  matrix  are 
shown  in  Figure  34. 
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Figure  34.  Coordinate  Frame  Relationship  Between  X-Monkey  Sensor  Frame 

and  Snowflake  Body  Frame 
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The  rotation  matrix  (. R )  was  also  converted  to  a  quaternion  vector  (Q)  to  aid  in 
post-flight  processing  as  well  as  to  facilitate  implementation  into  the  X-Monkey 
operating  software,  which  internally  utilized  quaternions.  Though  the  data  outputted  by 
the  X-Monkey  is  in  its  native  sensor  frame,  there  is  a  series  of  internal  routines  that 
incorporate  and  utilize  quaternion  rotation  sequences.  The  author  expects  that  Lieutenant 
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Similarly,  the  same  coordinate  transformation  was  applied  to  the  X-Monkey  Euler 
angle  rates  ( cp ),  (6)  and  (xp)  to  transform  the  values  to  Snowflake  Euler  angle  rates  in 
post- flight  processing. 


2.  Lab  Testing 

To  confirm  the  correct  operation  of  the  quaternion  operator  identified  earlier,  the 
author  conducted  a  series  of  laboratory  experiments.  In  each  experiment,  an  X-Monkey 
was  installed  as  shown  in  Figure  34  and  multiple  scripted  experiments  were  conducted. 
Primarily,  the  Snowflake  was  rotated  360  degrees  of  positive  pitch,  360  degrees  of 
positive  roll  and  360  degrees  of  positive  yaw.  The  experiment  took  approximately  30 
seconds  to  complete  and  included  downloading  the  experimental  data  file  from  the  X- 
Monkey  and  importing  into  MATLAB  for  processing  using  one  of  the  scripts  shown  in 
the  Appendix.  Representative  results  from  an  experiment  are  shown  in  Figures  35  and  36. 

The  Euler  angle  data  were  adjusted  in  MATLAB  to  convert  the  output  angles 
from  the  X-Monkey  to  a  more  useful  range.  The  range  of  roll  angles  was  converted  to  +/- 
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180  degrees,  the  pitch  angles  were  converted  to  +/-  90  degrees  and  the  yaw  angles  were 
converted  to  a  range  from  0-360  degrees  using  the  wrapToiso  function  in  MATLAB. 
The  roll  and  yaw  transients  exhibited  in  Figure  35,  which  occurred  during  the  360-degree 
positive  pitch  rotation,  were  expected  variations  associated  with  a  90  degree  pitch 
up/pitch  down  orientation. 


Snowflake  Euler  Angles 
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Figure  35.  Lab  Experiment  Results:  Snowflake  Euler  Angles  following 

Coordinate  Transformation 

Additionally,  the  Euler  angle  rates  recorded  during  this  experiment  were  also 
shifted  from  the  X-Monkey  orientation  to  the  more  appropriate  Snowflake  orientation  as 
shown  in  Figure  36.  The  raw  sensor  output  data  were  filtered  using  a  one  dimensional 
median  filter  function  (medfiiti)  in  MATLAB  to  reduce  some  of  the  high  frequency 
noise  in  the  rate  sensors  and  to  make  the  experimental  output  a  bit  more  intuitive. 
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Snowflake  Roll,  Pitch,  and  Yaw  Rates 
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Figure  36.  Lab  Experiment  Results:  Snowflake  Euler  Angle  Rates  following 

Coordinate  Transformation 


3.  Flight  Tests 

From  February  18-19,  2016,  12  live  flight  experiments  were  conducted  at 
McMillan  Airfield,  Camp  Roberts,  CA  utilizing  the  Snowflake  ADS  with  an  installed  X- 
Monkey.  Each  of  these  flights  utilized  the  double  static  line  release  sequence,  with  1 1  of 
12  flights  resulting  in  a  full  canopy  inflation.  The  one  failure  was  attributed  to  a  snag  in 
the  parachute  support  lines  when  utilizing  a  spreader,  which  was  subsequently  removed. 
Comprehensive  post-flight  data  analysis  was  conducted  to  gain  insight  into  the  dynamics 
associated  with  launch,  separation  from  releasing  aircraft  and  steady  state  autonomous 
flight.  In  each  of  these  experiments,  the  control  line  retraction  was  systematically  varied 
to  induce  a  heading  change  in  the  platform.  This  data  was  to  be  utilized  to  construct  a 
SISO  model  of  the  Snowflake  for  subsequent  control  system  design.  The  principal 
objectives  of  these  tests  were  to  validate  the  airframe  separation  mechanism  and  to 
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collect  meaningful  data  on  the  flight  profile.  Both  of  which  were  achieved.  The  data 
shown  in  Figures  37  through  42,  are  from  a  single  flight  which  was  representative  of  each 
of  the  12  flight  experiments.  In  this  particular  example,  the  Snowflake  was  programmed 
with  a  two-centimeter  retraction  of  the  right  control  line  to  induce  a  positive  yaw. 

A  bird’s-eye  view  of  the  GPS  position  of  the  Snowflake  is  shown  in  Figure  37 
shortly  after  release  from  the  launch  aircraft  at  an  altitude  of  approximately  2,000  above 
ground  level  (AGL).  As  the  double  static  line  sequence  was  utilized,  the  Snowflake 
release  and  parachute  deployment  occurred  nearly  simultaneously.  The  author  defined  a 
steady  state  period  of  autonomous  Snowflake  flight  beginning  five  seconds  after 
parachute  deployment  to  five  seconds  before  touchdown.  This  helped  in  isolating  the 
dynamics  and  oscillations  associated  with  parachute  release.  The  flight  control  program  is 
designed  to  actuate  following  this  transient  condition  and  provide  guidance  to  the  pre¬ 
programmed  destination.  The  isolation  of  the  five  seconds  prior  to  touchdown  was  done 
to  facilitate  scaling  during  data  analysis  as  the  transients  on  landing  tended  to  mask  the 
steady  state  flight  characteristics. 
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Camp  Roberts  Bird's-Eye  View 
McMillan  Airfield,  Camp  Roberts,  CA 


Figure  37.  Flight  Test  Results:  Bird’s-Eye  View 

The  same  flight  experiment  is  represented  three-dimensionally  in  Figure  38.  The 
canopy  deployment,  steady  state  definitions  and  touchdown  points  are  all  shown. 
Additionally,  the  flight  profile  is  displayed  using  sensor  input  from  the  X-Monkey 
barometric  altimeter  as  well  as  the  altitude  reported  from  the  internal  GPS.  In  this 
example,  there  is  a  distinct  difference  between  the  two,  but  a  comprehensive  analysis  of 
all  test  results  demonstrated  significant  unreliability  in  the  accuracy  of  the  GPS  position 
and  altitude.  Until  the  source  of  the  GPS  instability  can  be  isolated,  usage  of  the 
barometric  altimeter  is  recommended.  Additionally,  analysis  of  the  discrepancy  between 
the  two  altitude  sensors  will  be  required  to  determine  precise  estimate  of  the  above 
ground  level  (AGL)  altitude  in  order  to  refine  terminal  control  and  accuracy. 
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Camp  Roberts  3  Dimensional  View 
McMillan  Airfield,  Camp  Roberts,  CA 
18-Feb-201 6  21:03:00 
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Figure  38.  Flight  Test  Results:  Three-Dimensional  View 


More  data  from  this  flight  experiment  are  shown  in  Figure  39,  which  shows  a 
clear  delineation  of  the  three  separate  elements  of  the  flight,  additional  levels  of  detail  in 
the  GPS  sensor  as  well  as  the  magnitude  of  total  acceleration  recorded  by  the  three-axis 
accelerometers  within  the  X-Monkey.  The  top  plot  of  the  altitude  profile  is  combined 
with  the  second  plot  of  total  acceleration  to  define  significant  flight  events  for  data 
analysis.  The  acceleration  spikes  at  approximately  350  seconds,  630  seconds  and  750 
seconds,  represent  the  catapult  launch  of  the  UAV,  the  release  of  the  Snowflake  ADS  and 
the  impact  with  the  ground.  Various  other  conditions  were  investigated,  but  the  total 
acceleration  was  deemed  most  reliable  in  isolating  these  significant  flight  events. 
Additionally,  in  the  top  plot  of  Figure  39,  the  erroneous  altitude  reported  by  the  GPS 
sensor  is  shown. 
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Full  Altitude  Profile 
McMillan  Airfield,  Camp  Roberts,  CA 
18-Feb-201 6  21:03:00 
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Figure  39.  Flight  Test  Results:  Altitude  Profile,  Total  Acceleration  and  GPS 

Ground  Speed/Track 


The  Snowflake  autonomous  flight  segment  is  expanded  in  Figure  40  to  reveal  the 
individual  components  of  the  velocity  as  reported  by  the  GPS  in  the  X-Monkey.  The 
north  and  east  components  (Vn  and  Ve)  are  shown  in  the  top  plot,  the  down  component 
(Vo)  in  the  second  plot  and  the  composite  ground  track  velocity  component  (Vg)  in  the 
bottom  plot.  The  ground  velocity  was  calculated  in  post-flight  processing  using  the 
following  expression: 

Va  =  J(V„f+{VE)2 

The  mean  values  for  the  down  and  ground  component  velocities,  ( Vo)  and  (Vg), 
respectively,  were  calculated  and  are  shown  in  Figure  40  as  well.  The  ground  velocity 
value  (Vg)  is  useful  for  completing  real  time  wind  estimation,  though  the  X-Monkey  will 
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need  an  installed  onboard  airspeed  sensor  in  subsequent  design  iterations  if  this 
functionality  is  to  be  implemented  successfully.  Providing  there  is  little  or  negligible 
vertical  wind  component,  the  GPS  vertical  velocity  component  (Vo)  is  sufficiently 
accurate  to  facilitate  flight  path  prediction  and  glideslope  management  in  the  terminal 
phase. 

GPS  Velocity  Data 

McMillan  Airfield,  Camp  Roberts,  CA 
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Figure  40.  Flight  Test  Results:  Snowflake  Autonomous  Flight  GPS  Velocity 

Components 

The  Euler  orientation  of  the  Snowflake  during  this  autonomous  flight  segment  is 
shown  in  Figure  41.  Unfortunately,  the  data  shown  highlight  a  problem  with  the  magnetic 
calibration  of  the  X-Monkey  that  manifested  itself  in  flight-testing.  The  hardware  version 
of  the  X-Monkey  had  an  internal  software  error  that  has  since  been  corrected.  The  magnetic 
calibration  reference  vector  was  not  being  saved  correctly,  which  produced  the  erroneous 
yaw  angles  represented  in  the  data.  From  the  flight  path  reconstruction  data  presented 
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earlier  in  Figures  37  and  38,  the  Snowflake  executed  two  right  360-degree  rotations  about 
the  yaw  axis,  but  the  recorded  Euler  headings  are  within  a  range  of  75  to  150  degrees. 


Snowflake  Euler  Angles 
McMillan  Airfield,  Camp  Roberts,  CA 
18-Feb-201 6  21:03:00 


Figure  41.  Flight  Test  Results:  Snowflake  Euler  Angles 


Figure  42  shows  an  expanded  comparison  of  the  Euler  yaw  heading  and  the  GPS 
ground  track  during  the  period  of  autonomous  Snowflake  flight.  Again,  the  erroneous 
heading  information  is  shown,  but  this  comparison  is  expected  to  be  useful  for 
conducting  a  real-time  wind  estimation.  The  magnetic  reference  vector  calibration  error 
has  subsequently  been  corrected,  and  the  correct  Euler  orientations  have  been  verified 
correct  in  a  series  of  lab  experiments  conducted  in  the  ADSC  lab. 
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Yaw  Angle  vs  GPS  Ground  Track 
McMillan  Airfield,  Camp  Roberts,  CA 
18-Feb-2016  21:03:00 


Figure  42.  Flight  Test  Results:  Snowflake  Yaw  Angle  versus  GPS  Ground 

Track 

Finally,  a  representative  flight  sequence  of  the  Snowflake  ADS  is  shown  in  Figure 
43.  This  sequence  is  a  compilation  of  several  flights  showing  the  diverse  nature  of  the 
experiments.  The  Snowflake  ADS  was  successfully  employed  from  two  different  types  of 
UAVs,  utilized  three  uniquely  developed  separation  sequences,  incorporated  two 
different  autopilot  computers  and  collected  experimental  data  from  autonomous  as  well 
as  radio  controlled  back-up  modes.  The  data  collected  and  the  methods  for  analysis  are 
presented  to  assist  future  research  endeavors  in  refining  the  control  and  guidance 
algorithms  to  enhance  terminal  accuracy. 
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Figure  43.  Compiled  Snowflake  ADS  Test  Sequence 


C.  SUMMARY 

This  chapter  compiled  the  65  flight  tests  conducted  over  a  nearly  ten-month 
period,  as  well  as  several  simulations  conducted  in  the  ADSC  laboratory  at  NPS.  The 
results  from  the  flight  tests  are  correlated  with  sequential  improvements  in  the  parachute 
deployment  methods  that  were  derived  from  failure  mode  analysis.  Additionally,  the 
ability  of  each  autopilot  to  capture  and  retain  valid  experimental  data  is  described,  as  it 
directly  influenced  the  author’s  conversion  from  the  Pixhawk  to  the  X- Monkey  flight 
computer.  Once  successful  flight  data  was  recorded,  this  chapter  detailed  various  lab 
simulations  and  the  mathematics  used  to  convert  recorded  data  to  a  more  useful 
coordinate  frame  using  quaternions.  Subsequently,  a  representative  flight  profile  is 
described  and  illustrated  to  facilitate  follow-on  control  system  development.  The  results 
from  these  flight  and  computer  simulations  are  used  to  derive  several  conclusions  relating 
to  the  viability  of  COTS  technology  to  produce  low-cost  micro-light  weight  PADSs  that 
can  provide  additional  capability  to  the  battlefield. 
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VI.  CONCLUSION  AND  RECOMMENDATIONS 


A.  CONCLUSION 

Based  on  theoretical  analysis  and  assessment  of  the  flight-test  results,  the  author’s 
overall  conclusion  is  that  low-cost,  COTS  navigation  components  are  likely  to  provide 
sufficient  accuracy  and  reliability  to  close  the  capability  gap  between  the  PADSs 
currently  in  operation  and  the  combat  operational  need  for  rapid-response,  tactical 
logistical  resupply  in  austere  and  dispersed  locations.  More  research  is  needed  to  provide 
conclusive  evidence  as  to  the  economic  viability  of  a  highly  accurate,  purpose  built 
micro-light  weight  class  PADSs  when  contrasted  with  potential  multiple  use  alternatives. 

In  addition  to  the  above  conclusion,  several  additional  conclusions  are  offered  to 
address  the  secondary  research  objectives.  Operational  limitations  for  employment  are 
discussed  as  well  as  several  conclusions  derived  from  the  application  of  systems 
engineering  methodologies  to  the  construction  of  several  initial  prototypes  and  the 
completion  of  a  technical  research  effort  at  NPS. 

1.  Operational  Employment  Limitations  of  Micro-Light  Weight  PADSs 

The  accuracy  of  the  Snowflake  ADS  is  still  being  developed  and  enhanced, 
however  this  research  effort  has  realized  some  potential  shortcomings  associated  with 
operational  employment.  Micro-light  weight  PADSs  have  an  inherent  requirement  to  be 
small  and  inexpensive  to  alleviate  the  warfighter  from  being  required  to  retain  and  return 
the  PADS  for  reuse.  If  the  cost  or  complexity  associated  with  a  micro-light  weight  PADS 
grows  to  the  point  where  it  can  no  longer  be  considered  disposable,  then  it  becomes 
questionable  as  to  whether  a  PADS  is  the  preferred  method  for  logistical  delivery.  Only 
in  the  specific  case  when  long-range  resupply  is  required,  is  a  PADS  able  to  outperform  a 
small  package  delivered  via  more  conventional  vertical  takeoff  and  landing  UAS,  such  as 
a  quad  copter. 

As  this  research  uncovered,  the  cost  to  commercially  procure  a  single  rectangular 

ram-air  parachute  is  approximately  $400.  Viable  economy  of  scale  production  will  most 

assuredly  reduce  the  cost  to  construct  a  ram-air  parachute  with  sufficient  build  quality  to 

75 


support  failure  rate  reduction.  Though  this  research  did  not  include  a  full  cost  analysis  to 
procure  a  developed  system,  cost  efficiency  must  be  balanced  with  the  requirement  for 
increased  terminal  accuracy.  As  the  burdening  of  a  tactically  engaged  warfighter  with  the 
responsibility  to  return  a  purpose-built  ram-air  parachute  is  undesirable,  continued 
improvements  in  micro-light  PADSs  must  be  implemented  in  a  manner  which  retains  the 
attribute  of  being  a  single-use  item. 

This  conclusion  was  reached  as  a  result  of  the  application  of  the  systems 
engineering  methodology  to  research  and  understand  the  core  user/stakeholder  needs  and 
resultant  requirements.  The  need  demonstrated  by  the  hypothetical  user  in  most 
CONOPS,  is  for  logistical  resupply,  not  for  logistical  resupply  via  PADS.  As  such,  the 
systems  engineering  methodology  was  an  effective  tool  in  the  development  of  the 
Snowflake  ADS  in  that  it  had  to  be  the  best  approach  to  meeting  the  core  stakeholder 
needs. 


2.  Application  of  Systems  Engineering  Methodology 

Traditional  and  Agile  methodologies  were  critical  tools  in  the  conceptual  and 
preliminary  design  of  a  micro-light  weight  class  PADS.  The  ability  to  rapidly  respond  to 
failures,  identify  root  causes  and  incorporate  multiple  design  changes  though  iteration 
was  critical  in  development.  Additionally,  the  ability  to  identify  emerging 
user/stakeholder  needs  and  rapidly  iterate  accordingly  was  instrumental  to  the  success 
that  was  achieved.  Lastly,  the  application  of  various  design  thinking  principles  to  identify 
solutions  based  on  desired  functionality  enhanced  development  when  contrasted  to 
component  specific  solutions. 

3.  Prototype  Design  for  Operational  as  Compared  to  Developmental 
Objectives 

Though  the  systems  engineering  principles  identified  earlier  were  instrumental  in 
design,  there  were  some  identified  shortfalls  in  a  design  focused  purely  on  the  end  users 
specified  needs.  Analysis  of  stakeholder  needs  was  crucial  and  valuable,  but  it  did  not 
necessarily  produce  an  effective  “Big  Design  Up  Front”  in  the  conceptual  and 
preliminary  design  phases.  The  number  of  design  iterations  required  simply  to  support 
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developmental  testing  was  significant.  As  such,  it  was  necessary  to  identify  additional 
effective  needs  for  various  phases  of  development  in  order  to  successfully  design  a 
prototype  suitable  for  operational  employment. 

4.  Integration  of  Multi-Domain  NPS  Engineering  Curriculum 

The  most  rewarding  aspect  of  this  research  endeavor  has  been  the  ability  to 
engage  with  engineering  faculty  and  students  outside  of  the  Systems  Engineering 
Department  at  NPS.  The  author  believes  that  the  quantity  and  quality  of  learning  was 
magnified  significantly  through  the  application  of  the  systems  engineering  methodology 
to  an  ongoing  engineering  project,  commencing  with  initial  design  and  culminating  with 
field  experimentation.  This  research  has  allowed  the  author  to  investigate  robotic 
fundamentals,  unmanned  systems  navigation  systems  and  classic  control  while  designing 
and  integrating  a  complete  PADS. 

In  contrast,  the  author  strongly  believes  that  the  application  of  systems 
engineering  toward  an  abstract  or  theoretical  problem  is  counterproductive.  Systems 
engineering  education  must  include  the  application  of  concepts  toward  a  complex  applied 
engineering  effort.  Failure  to  do  so  is  a  disservice  to  the  both  the  system  engineer  and  the 
teams  of  domain  specific  engineers.  The  author  frequently  observed  how  a  domain 
specific  engineer  could  focus  on  a  specific  solution  and  lose  sight  of  the  broader 
functionality  that  was  trying  to  be  achieved.  The  systems  engineering  methodology  was 
useful  in  this  regard.  In  contrast,  an  abstract  systems  engineer  who  lacks  a  basic 
understanding  of  the  underlying  engineering  complexity  associated  with  design  and 
testing  lends  little  to  the  project. 

5.  Continuity  and  Documentation  of  Research  Effort 

The  author  began  this  research  endeavor  with  the  intention  of  improving  the 

results  of  previous  students.  Unfortunately,  the  lack  of  continuity  in  the  project 

contributed  greatly  to  the  overall  complexity  and  difficulty.  The  author  spent  close  to 

nine  months  getting  the  research  platform  back  to  the  level  of  capability  where  it  was  a 

few  years  ago.  As  software  and  hardware  are  revised  continually,  the  period  of  viability 

associated  with  the  equipment  in  any  research  project  is  much  shorter  than  expected.  For 
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the  Snowflake  ADS,  or  any  research  project  to  continue  to  evolve  and  improve,  there 
must  be  a  continuous  supply  of  students  or  laboratory  technicians  who  are  familiar  with 
the  technical  specifications  of  the  project. 

B.  RECOMMENDATIONS  FOR  TECHNICAL  IMPROVEMENTS 

The  recommendations  provided  are  a  small  sample  of  the  technical  areas  in  which 
the  Snowflake  ADS  prototype  could  be  improved  to  enhance  its  navigational  accuracy 
and  associated  operational  utility.  As  the  final  prototype  is  suitable  for  subsequent 
scientific  experimentation,  significant  room  for  improvement  exists  before  the  utility  of  a 
micro-light  weight  class  PADS  can  be  fully  explored  in  an  operational  setting. 

1.  Guidance  and  Control  Algorithms 

The  parallel  effort  of  Lieutenant  Commander  O’Brian  to  implement  a  guidance 
and  control  algorithm  into  the  X-Monkey  autopilot  is  a  significant  undertaking,  but 
necessary  for  the  development  of  autonomous  navigation.  Due  to  the  earlier  described 
failures  in  the  preliminary  design,  the  author  was  not  able  to  collect  comprehensive  data 
to  assist  in  developing  a  SISO  model  linking  control  line  retraction  to  Snowflake  yaw 
angle.  The  late  transition  from  the  Pixhawk  autopilot  to  the  X-Monkey  autopilot 
contributed  to  the  latency  in  developing  a  control  algorithm  as  the  two  autopilots  are 
programmed  completely  differently. 

In  addition  to  the  SISO  control  line  retraction  to  yaw  rate  model,  a  multiple  input 
multiple  output  (MIMO)  model  can  be  created  to  simultaneously  control  the  yaw,  provide 
some  measure  of  roll  damping  during  the  descent  as  well  as  offer  pitch  response  to 
accommodate  changes  in  forward  velocity.  The  dual  input  associated  with  independent 
actuation  of  the  left  and  right  control  lines  can  be  used  to  examine  a  variety  of  outputs 
through  the  use  of  state  space  design  techniques. 

2.  Robustness  of  GPS  Navigation  Solution 

Experiments  conducted  using  the  X-Monkey  demonstrated  some  small  reliability 
inconsistencies  with  the  GPS  sensor  data.  Due  to  the  relatively  low  power  of  a  received 
GPS  signal  and  the  internally  mounted  X-Money,  future  design  iterations  must  include 
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the  external  GPS  antenna  to  boost  signal  reception.  If  the  external  antenna  does  not 
provide  the  necessary  additional  signal  strength,  then  a  pre-flight  verification  of  GPS 
signal  strength  is  necessary  prior  to  experimentation.  As  the  X-Monkey  can  be  expected 
to  sustain  a  roughly  5  G  impact  on  landing,  the  veracity  of  the  navigation  solution  must 
be  confirmed  prior  to  follow-on  experimentation. 

3.  Wind  Estimation 

To  enhance  the  accuracy  of  the  Snowflake  ADS,  the  AGU  must  be  able  to 
measure  and  refine  real-time  wind  speed  and  direction.  The  integration  of  an  externally 
mounted  airspeed  sensor  to  the  X-Monkey  was  considered,  but  not  implemented  in  the 
course  of  this  research  due  to  insufficient  time  and  available  flight-testing.  External 
airspeed  sensors  increase  the  risk  for  parachute  tangles/malfunctions  on  deployment  and 
are  unlikely  to  have  the  precision  required  for  low-airspeed  flight  and  wind  estimation 
with  rapidly  changing  platform  orientation.  One  of  several  potential  wind  estimation 
maneuvers  could  be  completed  during  descent  and  incorporated  into  the  guidance  and 
control  algorithms.  These  methods  are  designed  to  measure  and  adjust  to  a  continually 
changing  wind  profile  during  platform  descent  and  offer  precision  that  an  airspeed  sensor 
is  unlikely  to  provide  in  a  low-speed  dynamic  flight  envelope. 

4.  Improved  Parachute  Design 

This  research  effort  commenced  with  the  objective  of  assessing  the  potentially 
enhanced  maneuverability  of  elliptical  ram-air  parachutes  with  regard  to  micro-light 
weight  class  PADSs.  Unfortunately,  the  manufacturing  quality  of  the  elliptical  parachutes 
was  not  sufficient  to  support  experimentation.  However,  the  question  remains  as  to 
whether  the  elliptical  parachutes  can  offer  greater  maneuverability  and  the  potentially 
resultant  increase  in  terminal  accuracy.  If  a  ram-air  parachute  becomes  available,  the 
Snowflake  ADS  is  still  a  viable  test  platform  to  support  more  exhaustive  examination  of 
its  flying  qualities. 
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5.  Incorporation  of  an  Imaging  Sensor 

Previous  versions  of  the  Snowflake  ADS  had  limited  integration  of  a  monocular 
vision  sensor  to  assist  in  the  acquisition  of  a  non-cooperative  mobile  target  and 
navigation  in  the  GPS-denied  environment.  Unfortunately,  the  author  was  not  able  to 
incorporate  a  vision  sensor,  due  to  the  late  transition  to  the  X-Monkey  platform.  Though 
an  imaging  sensor  could  assist  in  the  terminal  phase  of  a  precise  delivery  for  a  mobile 
target,  it  could  also  assist  in  pose  estimation  in  a  GPS  denied  or  degraded  environment. 
As  such,  the  incorporation  of  an  imaging  sensor  does  potentially  increase  the 
technological  and  cost  complexity  past  the  threshold  for  operational  feasibility  for  a 
micro-light  weight  class  PADS.  Notwithstanding,  the  concept  is  still  potentially  viable  to 
augment  terminal  accuracy  for  larger  PADSs  that  are  not  considered  to  be  single  use 
items,  especially  in  the  GPS  denied  environment. 
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APPENDIX.  MATLAB  SCRIPTS 


A.  FUNCTION  TO  CONVERT  SENSOR  DATA  TO  BODY  FRAME 

This  function  was  used  multiple  times  in  analysis  of  both  laboratory  experiments 
and  flight  data  to  convert  the  Euler  orientation  of  the  X-Monkey  sensor  to  a  more  useful 
Euler  orientation  of  the  Snowflake. 


function  [SFeul]  =  XMeul2SFeul ( eul ) 

%This  function  accepts  user  input  of  a  [1x3]  vector  of  Euler  angles  in 
%degrees.  Input  Euler  angles  [roll  pitch  yaw].  This  rotates  the  Euler 
%angles  output  from  X-Monkey  to  the  Snowflake  orientation.  Use  to 
%convert  raw  X-Monkey  data  to  generate  flight  profile  of  SF.  Since  X- 
%Monkey  outputs  roll  in  0—360,  and  yaw  in  0—360,  this  function  wraps 
%the  data  to  roll=+/-180  and  yaw=+/-180  for  computation.  Output  wraps 
%the  yaw  to  0—360  for  heading  output. 

eul=wrapTol80 ( eul ) ; 
qM_I=eul2quat ( eul ) ; 
qI_S= [0.5  0.5  0.5  -0.5]'; 
qM_S=q_mult ( qM_I , qI_S ) ; 

SFeul ( 1 ) =atan2 ( 2  * ( qM_S ( 3 ) *qM_S ( 4 ) +qM_S ( 1 ) *qM_S ( 2 ) ) , 

( 1 - ( 2  * ( qM_S (2)^2  +qM_S (  3  )  A  2  ) ) ) ) ; 

SFeul(2)=-asin(2*(qM_S(2)*qM_S(4)-qM_S(l)*qM_S(3) ) ) ; 

SFeul ( 3 ) =atan2 ( 2  * ( qM_S ( 2 ) *qM_S ( 3 ) +qM_S ( 1 ) *qM_S ( 4 ) ) , 

( 1 - ( 2  * ( qM_S (  3  )  A  2  +qM_S ( 4 ) A  2 ) ) ) ) ; 

SFeul=rad2deg ( SFeul ) ; 

SFeul ( 3 ) =wrapTo360 ( SFeul ( 3 ) ) ; 
end 

B.  SCRIPT  TO  ANALYZE  LABORATORY  ORIENTATION  EXPERIMENTS 

This  script  was  used  to  rotate,  analyze  and  confirm  the  correct  orientation  of  the 
Euler  data  recorded  by  the  X-Monkey  to  the  more  appropriate  Snowflake  frame  for  use  in 
subsequent  flight-testing.  It  utilizes  the  Euler  angle  conversion  function  created 
separately. 


%  Snowflake  X-Monkey  Data  Processing 
close  all;  clear  all;  clc; 

%%  Read  in  the  data  file  you  want  to  process  that  include  YMDHM 
%sequence : 
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%Note:  This  takes  an  X-Monkey  CSV  file  which  must  be  generated  using 
%the  PARSR  Program.  Add  the  4-digit  year  to  the  beginning  of  the  data 
%file  name. 

[filename,  pathname]  =  uigetf ile ( ' *. csv ',' Choose  First  X-Monkey  data 
file ' ) ; 

FileName  =  [pathname  filename]; 
iD=strf ind ( filename ,'201'); 

YY=str2num( filename ( iD : iD+3 ) ) ;  Mo=str2num( filename ( iD+4 : iD+5 ) ) ; 

DD=str2num( filename ( iD+6 : iD+7 ) ) ;  HH=str2num( filename ( iD+8 : iD+9 ) ) ; 
Mi=str2num( filename ( iD+10 : iD+11 ) ) ; 

DateNumber 0=datenum ( YY , Mo , DD , HH , Mi , 0 ) ; 

Datestring  =  datestr ( DateNumberO ) ; 

File  =  csvread ( FileName , 1 , 0 ) ; 

choice  =  questdlg( 'Would  you  like  to  enter  another  file  from  this 
experiment? ' , 'Additional  Files ' ) ; 

YN=strcmp ( choice , ' Yes ' ) ; 

while  YN  ==  1 

[filename,  pathname]  =  uigetf ile ('*. csv ',' Choose  Another  X-Monkey 
data  file ' ) ; 

FileName  =  [pathname  filename]; 

File  =  vertcat ( File , csvread ( FileName , 1 , 0 )) ; 

choice  =  questdlg( 'Would  you  like  to  enter  another  file  from  this 
experiment? ' , . . . 

'Additional  Files ' ) ; 

YN=strcmp ( choice , ' Yes ' ) ; 

end 

eul=[File( : ,28)  File(:,29)  File(:,30)]; 

[ M,  N ] =  size ( eul ) ; 

SFeul  =  zeros(M,N); 
for  i=l:M 

SFeul ( i , : ) =XMeul2SFeul ( eul ( i , : ) )  ; 
end 

%%  Create  Plot  of  X-Monkey  Roll,  Pitch,  and  Yaw 
figure ( 1 ) 
subplot ( 311 ) 

plot ( File ( : ,5) ,File( :  ,28) ) 
title (' X-Monkey  Euler  Angles'); 
ylabel ( 'Roll  ( Ao) ' ) ; 
axis  tight 

subplot (312) 

plot ( File ( : ,5) ,File( s  ,29) ) 
ylabel ( 'Pitch  ("o)'); 
axis  tight 

subplot (313) 

plot ( File ( : ,5) ,File( :  ,30) ) 
ylabel('Yaw  (^o)'); 
xlabel('Time  (s)'); 
axis  tight 


82 


%%  Create  Plot  of  Roll,  Pitch,  and  Yaw 
figure ( 2 ) 
subplot ( 311 ) 

plot ( File ( : , 5 ) , SFeul ( : , 1 )  ) 
title (' Snowflake  Euler  Angles'); 
ylabel ( 'Roll  ( Ao) ' ) ; 
axis  tight 

subplot (312) 

plot ( File ( : ,5) , SFeul ( : ,2)  ) 
ylabel ( 'Pitch  ("o)'); 
axis  tight 

subplot (313) 

plot ( File ( : ,5) , SFeul ( : ,3)  ) 
ylabel('Yaw  (^o)'); 
xlabel ( ' Time  (s)'); 
axis  tight 

%%  Create  Euler  Rate  Plots 
figure ( 3 ) 
subplot ( 311 ) 

f ilterroll=medf iltl ( -File (s, 37), 500); 
plot ( File ( : ,5) ,-File( : ,37) ) 
hold  on 

plot ( File ( : , 5 ) , f ilterroll , ' r ' , ' LineWidth ' , 2 ) 
title (' Snowflake  Roll,  Pitch,  and  Yaw  Rates'); 
legend ( 'Raw  Sensor  Output ',' Filtered  Sensor 
Output' , 'Location' , 'northwest' ) ; 
ylabel('Roll  rate  (Ao/s)'); 
axis  tight 
hold  off 

subplot (312) 

f ilterpitch=medf iltl ( File ( : , 35 ) , 500  )  ; 
plot ( File ( : ,5) ,File( : ,35)  )  ; 
hold  on 

plot ( File ( : , 5 ) , f ilterpitch, ' r ' , 'LineWidth ' , 2 ) ; 
ylabel (' Pitch  rate  (Ao/s)'); 
axis  tight 
hold  off 

subplot (313) 

f ilteryaw=medf iltl ( -File (s, 36), 500); 
plot ( File ( : ,5) ,-File( : ,36) )  ; 
hold  on 

plot ( File ( : , 5 ) , f ilteryaw, ' r ' , ' LineWidth ' , 2 ) ; 

ylabel('Yaw  rate  (Ao/s)'); 

xlabel ('Time  (s)'); 

axis  tight 

hold  off 
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c. 


SCRIPT  TO  MERGE  X-MONKEY  .CSV  FILES  TO  SINGLE  .MAT  FILE 


This  script  was  used  to  combine  the  series  of  .csv  files  that  were  outputted  by  the 
X-Monkey.  Due  to  some  hardware  limitations  internal  to  the  X-Monkey,  each  output  data 
file  is  only  7Mb.  Following  the  experiment,  the  series  of  .csv  fdes  can  be  merged  to  a 
single  .mat  file  to  speed  up  analysis. 


%%  Script  for  merging  multiple  .csv  files  into  a  single. mat  file 
%  First  redefine  the  YYYYMMDDSF (#) D ( Drop#) .mat  file  at  the  end 
%  Import  any  number  of  .csv  files,  creates  .mat  file 
%  Move  .mat  file  to  appropriate  folder 

close  all;  clear  all;  clc 

[filename,  pathname]  =  uigetf ile ( ' *. csv Choose  First  X-Monkey  data 
file ' ) ; 

FileName  =  [pathname  filename]; 
iD=strf ind ( filename ,'201'); 

YY=str2num( filename ( iD : iD+3 ) ) ;  Mo=str2num( filename ( iD+4 : iD+5 ) ) ; 

DD=str2num( filename ( iD+6 : iD+7 ) ) ;  HH=str2num( filename ( iD+8 : iD+9 ) ) ; 
Mi=str2num( filename ( iD+10 : iD+11 ) ) ; 

DateNumber 0=datenum ( YY , Mo , DD , HH , Mi , 0 ) ; 

Datestring  =  datestr ( DateNumberO ) ; 

File  =  csvread ( FileName , 1 , 0 ) ; 

choice  =  questdlg( 'Would  you  like  to  enter  another  file  from  this 
flight? ', 'Additional  Files'); 

YN=strcmp ( choice , ' Yes ' )  ; 

while  YN  ==  1 

[filename,  pathname]  =  uigetf ile ('*. csv ',' Choose  Another  X-Monkey 
data  file ' ) ; 

FileName  =  [pathname  filename]; 

File  =  vertcat ( File , csvread ( FileName , 1 , 0 )) ; 

choice  =  questdlg( 'Would  you  like  to  enter  another  file  from  this 
flight? ', 'Additional  Files'); 

YN=strcmp ( choice , ' Yes ' ) ; 

end 

save  20 1602 19SF4D3 .mat  %  Name  .mat  output  file  here 

D.  SCRIPT  TO  ANALYZE  X-MONKEY  FLIGHT  TEST  DATA 

This  script  uses  the  .mat  file  created  earlier  to  process  that  data  and  produce  a 
series  of  graphs  to  analyze  the  flight  profile. 

%%  Snowflake  X-Monkey  Data  Processing  using  a  .mat  file 
%  This  script  uses  a  full  .mat  file  from  the  flight 
%  User  selects  full  flight  file  and  processes  accordingly 
%  CSV  version  merges  the  files  and  then  processes 
%  To  use  this  version,  run  the  MergeFiles.m  script  once  and 
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%  Save  the  .mat  file  in  the  correct  directory 


close  all;clear  all;clc; 

[ filename ,  pathname ] =uigetfile ( ' * .mat Choose  X-Monkey  .mat  file'); 
f name=fullf ile (pathname, filename ) ; 
load( fname ) ; 

%%  Set  Variables 
Servo0neutral=14  9 1 ; 

Servolneutral=1508 ; 

%%  Set  Location 

testsite= 'McMillan  Airfield,  Camp  Roberts,  CA' ; 

%%  Calculate  Snowflake  Release  and  Parachute  Deployment 
Tskip=0 ; 

% [maxAlt , IndAlt ] =max ( File ( : , 22 ) ) ;  %Use  GPS  Altitude 

[maxAlt, IndAlt ]=max(File( : , 52 ) ) ;  %Use  Baro  Altitude 

Tskip=Tskip+IndAlt ; 

disp ([' Release  altitude  '  num2str (maxAlt , 3 )  '  m' ] ) 

%  Use  total  acceleration  to  find  launch,  release  and  land 
%  View  Figure  (1)  to  determine  what  exact  peaks  represent  and  adjust 
%  Smaller  data  files  may  not  have  all  three  events 
%  Cross  reference  with  altitude  plots  as  well 

Acceltot=sqrt ( File ( : ,32) . "2+File( : ,33) . "2+File( : ,34) . A2) ; 

[ pks , Iocs ]  =  f indpeaks ( Acceltot ,  'MINPEAKHEIGHT ' , 

4  0 , 'MinPeakDistance ' ,  1000 )  ; 

T20Launch=locs ( 1 )  ; 

SFChuteDeploy=locs ( 2 )  ; 

SFLand=locs ( 3 ) ; 

%T20Launch=locs ( 2 )  ; 

%SFChuteDeploy=locs ( 3 )  ; 

%SFLand=locs ( 4 ) ; 

ReleaseDelay=100*5 ;  %  Five  second  after  release 
LandCutoff =100*3 ;  %  Three  seconds  prior  to  ground  impact 

%ChuteOpenAlt  =  File ( SFChuteDeploy , 22 ) ;  %GPS  Altitude 
ChuteOpenAlt  =  File ( SFChuteDeploy , 52 ) ;  %Baro  Altitude 
%LandAlt=File ( SFLand, 22 ) ;  %GPS  Altitude 

LandAlt=File ( SFLand, 52 ) ;  %Baro  Altitude 

DropProfile  =  File ( SFChuteDeploy : SFLand, :) ; 

SSDropProf ile=File ( SFChuteDeploy+ReleaseDelay : SFLand-LandCutof f , : ) ; 
AltRange  =  ChuteOpenAlt  -  LandAlt; 

DescentTime  =  File ( SFLand, 5 ) -File ( SFChuteDeploy , 5 ) ; 

%%  Convert  X-Monkey  Euler  Angles  to  Snowflake  Euler  Angles 

eul= [ SSDropProf ile ( : , 28 )  SSDropProf ile ( : , 29 )  SSDropProf ile ( : , 30 ) ] ; 

[M,  N]=  size(eul) ; 
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SFeul  =  zeros(M,N); 
for  i=l:M 

SFeul ( i , : ) =XMeul2SFeul ( eul ( i , : ) ) ; 
end 

%%  Create  Birds-Eye  View  Plot 
figure ( 1 ) 
hold  on 

plot ( DropProf ile ( : , 2 1 ) , DropProf ile ( : , 20 ) , ' w- ' ) 
plot ( DropProf ile (1,21), DropProf ile (1,20), ' rs ' ) 
plot (SSDropProf ile (1,21) , SSDropProf ile ( 1 , 20 ) , 'y*' ) 
plot ( SSDropProf ile ( end, 21), SSDropProf ile ( end, 20 ) , ' bp  ) 
plot  ( DropProf  ile  ( end,  21),  DropProf  ile  ( end,  20  )  ,  '  gd ) 
plot_google_map ( 'MapType' , 'satellite' ) ; 

title ({' Camp  Roberts  Bird''s-Eye  View' ; testsite ; Datestring} ) ; 
h=legend( ' Trajectory ',' Canopy  Deployment ',' Steady  State  Begins',... 

'Steady  State  Ends ',' Touchdown ',' location ',' best ') ; 
set ( h, ' font size ' , 8 ) ; 

xlabel (' Latitude  (^o)'),  ylabel (' Longitude  (^o)') 
hold  off 

%%  Plot  3D  Profile 
figure ( 2 ) 
hold  on 

plot 3 ( DropProf ile ( : , 2 1 ) , DropProf ile ( : , 20 ) , DropProf ile (:,52),'-'); 
plot 3 ( DropProf ile ( : , 2 1 ) , DropProf ile ( : , 20 ) , DropProf ile ( : , 22 ) , ' — '); 
plot 3 ( DropProf ile (1,21), DropProf ile (1,20), DropProf ile (1,52), ' rs ' ) 
plot 3 ( DropProf ile (1,21), DropProf ile (1,20), DropProf ile (1,22), ' rs ' ) 
plot 3 ( SSDropProf ile (1,21), SSDropProf ile (1,20), SSDropProf ile (1,52), ' y* ' ) 
plot 3 ( SSDropProf ile (1,21), SSDropProf ile (1,20), SSDropProf ile (1,22), ' y* ' ) 
plot 3 ( SSDropProf ile ( end, 21), SSDropProf ile ( end, 20 ) , SSDropProf ile ( end, 52 ) 
,  '  bp '  ) 

plot 3 ( SSDropProf ile ( end, 21), SSDropProf ile ( end, 20 ) , SSDropProf ile ( end, 22 ) 

,  '  bp '  ) 

plot 3 ( DropProf ile ( end, 21), DropProf ile ( end, 20 ) , DropProf ile ( end, 52 ) , ' gd ' ) 
plot 3 ( DropProf ile ( end, 21), DropProf ile ( end, 20 ) , DropProf ile ( end, 22 ) , ' gd ' ) 

title({'Camp  Roberts  3  Dimensional  View' ; testsite; Datestring} ) ; 
legend ( 'Barometric  Altimeter' , 'GPS  Altimeter' , 'Canopy  Deployment 
( Baro )',... 

'Canopy  Deployment  ( GPS )',' Steady  State  Begins  ( Baro )',' Steady 
State  Begins  (GPS)',... 

'Steady  State  Ends  ( Baro )',' Steady  State  Ends  ( GPS ) ' , ' Touchown 
( Baro ) ' , ' Touchdown  ( GPS ) ' , ' Location ' , ' best ' ) ; 
xlabel (' Latitude  (^o)'); 
ylabel (' Longitude  (^o)'); 
zlabel ( 'Altitude  (m) ' ) ; 
zlim( [ 0  inf ] ) 
view( -28,27) 
grid 

hold  off 

%%  Plot  Full  Flight  Profile 
figure ( 3 ) ; 
subplot (411); 
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plot ( File ( : , 5) ,File( : , 22) ,File( : , 5) ,File( :  ,52)  ) 

title({'Full  Altitude  Prof ile '; testsite ; Datestring} ) ; 
ylabel ( 'Altitude  (m) ' ) ; 

legend ('GPS  Altitude ',' Baro  Altitude ',' Location ',' Best ' ) 
axis  tight 

subplot (412); 
plot ( File ( : , 5 ) , Accel tot ) 
title ( 'Total  Acceleration  ) ; 
ylabel ( ' a_{xyz }  (m/sA2)'); 
axis  tight 

subplot (413); 

plot ( File ( : , 5) ,File( : , 23) ) 
title ('GPS  Ground  Speed'); 
ylabel (' Ground  Speed  (m/s)'); 
axis  tight 

subplot (414); 

plot ( File ( : , 5) ,File( : ,24) ) 
title ('GPS  Ground  Track'); 
xlabel ( ' Time  (s)'); 
ylabel (' Degrees  (^o)'); 
axis  tight 

%%  Create  Plot  of  X-Monkey  Roll,  Pitch,  and  Yaw 
figure ( 11 ) 
subplot ( 311 ) 

plot ( SSDropProf ile ( : , 5 ) , eul ( : , 1 ) ) 

title ({ # X-Monkey  Euler  Angles '; testsite ; Datestring} ) ; 
ylabel ('\phi  (^o)'); 
axis  tight 

subplot (312) 

plot ( SSDropProf ile ( : , 5 ) , eul ( : , 2 ) ) 
ylabel ( '\theta  (Ao)'); 
axis  tight 

subplot (313) 

plot ( SSDropProf ile ( : , 5 ) , eul ( : , 3 ) ) 
ylabel('\psi  (^o)'); 
xlabel ('Time  (s)'); 
axis  tight 

%%  Create  Plot  of  Snowflake  Roll,  Pitch,  and  Yaw 
figure ( 5 ) 
subplot ( 311 ) 

plot ( SSDropProf ile ( : , 5 ) , SFeul ( : , 1 ) ) 

title ({' Snowflake  Euler  Angles '; testsite ; Datestring} ) ; 
ylabel ('\phi  (^o)'); 
axis  tight 

subplot ( 312 ) 

plot ( SSDropProf ile ( : , 5 ) , SFeul ( : , 2 ) ) 
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ylabel ( ' \theta  ( ) ' ) ; 
axis  tight 

subplot (313) 

plot ( SSDropProf ile ( : , 5 ) , SFeul ( : , 3 ) ) 
ylabel('\psi  (^o)'); 
xlabel ( ' Time  (s)'); 
axis  tight 

%%  Create  Euler  Rate  Plots 
figure ( 6 ) 
subplot ( 311 ) 

f rrate=medf iltl ( -SSDropProf ile (:,37),500); 
f prate=medf iltl ( -SSDropProf ile (:,35),500); 
f yrate=medf iltl ( -SSDropProf ile (:,36),500); 

plot ( SSDropProf ile ( : , 5 ) , -SSDropProf ile ( : , 37 ) ) 
hold  on 

plot ( SSDropProf ile ( : , 5 ) , f rrate , ' r ' , ' LineWidth ' ,2) 
title ({' Roll ,  Pitch  and  Yaw  Rates testsite ; Datestring} ) ; 
ylabel (' $\dot{ \phi}  (Ao/s)$f,  ' Interpreter ' , ' latex ' ) 

axis  tight 

subplot (312) 

plot ( SSDropProf ile ( : , 5 ) , SSDropProf ile ( : , 35 ) ) 
plot ( SSDropProf ile ( : , 5 ) , f prate , ' r ' , ' LineWidth ' ,2) 
ylabel ( ' $ \ dot { \ theta}  ( Ao/s ) $ ' f  ' Interpreter ' , ' latex ' ) 
axis  tight 

subplot (313) 

plot ( SSDropProf ile ( : , 5 ) , -SSDropProf ile ( : , 36 ) ) 
plot ( SSDropProf ile ( : , 5 ) , f yrate , ' r ' , ' LineWidth ' ,2) 
ylabel ( ' $\dot{ \psi}  (Ao/s)$'f  ' Interpreter ' , ' latex ' ) 

xlabel ('Time  (s)'); 
axis  tight 

%%  Create  Acceleration  Plots 
figure ( 7 ) 
subplot ( 311 ) 

plot ( SSDropProf ile ( : , 5 ) , SSDropProf ile ( : , 34 ) ) 
title ( { 'Accelerations ' ; testsite ; Datestring} ) ; 
ylabel (' a_{x}  (m/sA2)'); 
axis  tight 

subplot (312) 

plot ( SSDropProf ile ( : , 5 ) , SSDropProf ile ( : , 32 ) ) 
ylabel (' a_{y}  (m/sA2)f); 
axis  tight 

subplot (313) 

plot ( SSDropProf ile ( : , 5 ) , SSDropProf ile ( : , 33 ) ) 
ylabel (' a_{ z }  (m/s^2)'); 
xlabel ('Time  (s)'); 
axis  tight 
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%%  Create  Control  Input  Plots 
figure ( 8 ) 
subplot ( 211 ) 
hold  on 

plot ( SSDropProf ile ( : , 5 ) , SSDropProf ile ( : , 59 ) , ' Color ' , ' r ' ) 
hlineO=ref line ( 0 , ServoOneutral ) ; 
set(hlineO, 'LineStyle' , '  — ' )  ; 

title ({' Control  Line  Inputs  (Right )'; testsite; Datestring} ) ; 

y label (' Servo  Zero  Command  (PWM)'); 

ylim( [ Servo0neutral-150  Servo0neutral+150 ] ) ; 

hold  off 

subplot (212) 
hold  on 

plot ( SSDropProf ile ( : , 5 ) , SSDropProf ile ( : , 60 ) , ' Color ' , ' r ' ) 
hlinel=ref line ( 0 , Servolneutral ) ; 
set ( hlinel , 'LineStyle' , ' — '); 

title ({' Control  Line  Inputs  (Left )'; testsite ; Datestring} ) ; 

y label (' Servo  One  Command  (PWM)'); 

ylim( [ Servolneutral-150  Servolneutral+150 ] ) ; 

hold  off 

%%  Compare  Yaw  Angle  and  Ground  Track  Plot 
figure ( 9 ) 
hold  on 

plot ( SSDropProf ile ( : , 5 ) , SFeul ( : , 3 ) ) 

plot ( SSDropProf ile ( : , 5 ) , SSDropProf ile ( : , 24 ) ) 

title({'Yaw  Angle  vs  GPS  Ground  Track '; testsite ; Datestring} ) ; 
ylabel (' Yaw/Ground  Track  (^o)'); 
xlabel('Time  (s)'); 

legend ( 'Magnetometer  Heading' , 'GPS  Ground  Track' ) 
axis  tight 
hold  off 

%%  Three  axis  GPS  velocity 
figure ( 10 ) 

hold  on; 
subplot ( 311 ) 
hold  on 

plot ( SSDropProf ile ( : , 5 ) , SSDropProf ile ( : , 25 ) ) 
plot ( SSDropProf ile ( : , 5 ) , SSDropProf ile ( : , 26 ) , ' — ' ) 
title({#GPS  Velocity  Data '; testsite ; Datestring} ) ; 
ylabel ( 'V_{N;E}  (m/s) ' ) ; 

legend ( 'V_{N} ' , 'V_{E} ' , 'Location' , 'best' ) 
axis  tight 
hold  off 

subplot (312) 
hold  on 

plot ( SSDropProf ile ( : , 5 ) , SSDropProf ile ( : , 27 ) ) 
plot ( [ SSDropProf ile ( 1 , 5 )  SSDropProf ile ( end, 5 ) ] 

, mean (SSDropProf ile ( : ,27) )*[1  l],'-.r'); 

text ( SSDropProf ile (1,5) , mean ( SSDropProf ile ( : , 27 ) ) , [ 'mean  V_{D} 
num2str (mean ( SSDropProf ile ( : , 27 ) ) )  '  m/s ' ] ) ; 
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ylabel ( 'V_{D}  (m/s) ' ) ; 
axis  tight 
hold  off 

subplot (313) 

VG=sqrt ( SSDropProf ile ( : ,25) . "2+SSDropProf ile ( : ,26) ."2) ;  mVG=mean(VG) ; 
hold  on 

plot (SSDropProf ile ( : ,5) ,VG) 

plot ( [ SSDropProf ile (1,5)  SSDropProf ile ( end, 5 ) ]  ,mVG*[l  l],'-.r'); 

text ( SSDropProf ile (1,5) ,mVG, [ 'mean  V_{G}  =  '  num2str(mVG)  '  m/s']); 

ylabel ( 'V_{G}  (m/s) ' ) ; 

xlabel('Time  (s)'); 

axis  tight 

hold  off 
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